I have a very complex problem with transaction management. there is a session bean running on one weblogic server that makes a call to another session bean on another weblogic server running on second machine. the calling method has tx attribute as RequiresNew. The called method has tx attribute as NotSupported. What happens is like this:
1. Calling method f1() makes some local database updates
2. then f1 calls f2 on remote weblogic servers.
3.Method f1 finishes and changes in database are committed. However, the control does not come back to calling application.
4.then i see timeoutexception on my server's console as it waits for the remote weblogic server. I dont know what it wait for .
the error message is as follows :
javax.transaction.SystemException: Timeout during commit processing
5. This exception is thrown back to calling client. However, the local database update is not rolled back.
Can anybody explain me what is happening wrong in this scenario.
I am using non-XA driver.
Any help would be greatly appreciated.
If your second server is down or the call takes too much time, your calling method will wait for some amount of time and your transaction will not be commited (because it's getting timed out before you actually commit it). Your method calls are synchronous, so I don't understand what wonders you. If I were you, I'd either increase commit timeout value (if there is no way to decrease the waiting time) or provide better availability (in case if it's often down) or faster connection (to make the calls faster) for the second server. A good alternative - is to switch to asynchronous call model (powered by MDBs).
I think we faced a similar problem while using Websphere 4.01. This might be due to two reasons....
1) Since you are calling a Session Bean on a second server, weblogic might be considering this to be a 2PC since you are using a Non-XA driver. The solution to this might be to call a new method fNew() on the first server bean (Server1) which should have a transaction attribute as NotSupported and then let this new method - fNew() call the method f2() on the second server bean...This should solve the 2-PC problem if any....The other solution to this is to use an XA driver which is 2-PC aware.
2) Secondly, you could increase your transaction timeout variable using your Weblogic Admin console, by default it is 30 seconds, I guess. You can find this attribute in the "Servers" tab at the top of left pane of the console. Click on the "JTA" subtab on the right screen and you can set your new transaction timeout variable in Seconds...Be careful with this since this new timeout setting affects all the server instances running on the machine...
Hope this helps...
I think this problem is related to Database, might be some application/user is performing insert/update transaction on table and forgot to commit. So the table has been locked and its not allowing other application to perform operation and application is wating.
Plz ask ur DBA to execute same query on SQL prompt of that remote machine.
All the best.
Now a dayz no good database table will go in mutation when there is insert and update happening secondly the commit problem is specific to user and database is least bothers about what user does to it.
So this is not a database problem. All databases now a dayz go into row level or record level locks, that too at a very last moment.
Rashmi I guess you problem is with the call to another session bean. My gutt fealing is somewhere you are threading the call and are not callint it as a simple EJB call,
Just one query, how do u get the JNDI of the session bean of second application. and have you got the stub part of that session bean with your current JVM scope ?
One more thing, check EJB 2.0 spcs chapter 17. There it is specifically written that it does not support nested transaction. i.e.
trans start 1
trnas start 2
trans end 2
trans end 1
Is not allowed, but yes vendors may support it as a additional feature and I guess weblogic supports it very well. but I am not sure how it works when the call is going out of jvm.
damn this problem is bugging me, is it possible for you to send the code snippet and log so that we can take a detail look and see where is it blowingoff.
hope this helps
I think what's happening there is because EJB1 is set to "RequiresNew" and EJB2 is set to "NotSupported" when the logic leaves the boundary of EJB1 to call EJB2, even if EJB2 fails for some reason, Weblogic still commits the transaction within EJB1 because EJB2 is outside of the scope of the transaction. You might be catching a remote exception when you call EJB2 from EJB1 and not doing anything with it... if it's at all possible, throw an EJBException from EJB1, this way the container will interpret EJB1's method call as failing and thus not commit the transaction.