Re: More Re: [JBoss-user] When do entity beans commit?
Hi Georg, Regarding this problem I've been having -- thank you for all your thoughts and help. I have no idea why the code was executing inside a transaction, since the session bean method was definitely marked Never, and the entity bean Supports. Perhaps this is a bug, or perhaps the "spec-undefined" behavior of Supports+Entity Beans within jBoss has changed. In any case -- I have given up. I completely re-wrote that section of code using straight JDBC calls directly from the session bean method (with no use of entity beans); it now runs faster and I'm not getting any deadlocks. Regards, Bryan Georg Rehfeld wrote: 050501c0f480$ebc632c0$[EMAIL PROTECTED]">Dear Bryan, 6. Log messages from server.log - yes this message seemed toappear many hundred times in a row, around the time of mydeadlock:[staffBean] LOCKING-WAITING (TRANSACTION) for id com.theApp.ejb.staffPK@73ctx.hash 2702560 tx:TransactionImpl:XidImpl[FormatId=257, GlobalId=app-web1//188, BranchQual=] This clearly indicates access to an instance INSIDE a transactionthat already is associated to another TX. Interesting would be toknow if only staffBean with PK 73 is logged, or if other beansare involved/logged, and then which Transaction Global Id isshown there.In a true deadlock scenario you should see one instance loggedwith (in your case) 73 + app-web1//188 and at least one otherwith some other PK and Global Id (say 42 + app-web1//4711), inyour case I expect both of type staffBean, but in complexerscenarios it could be of some other type. And the true deadlockcase could even involve more beans cyclic waiting for each other.If you only see 73 + app-web1//188 LOCKING-WAITING it's morelikely, that the instance is participating in a lengthyprocessing, so that TX app-web1//188 finally gives up, althoughnow true deadlock condition exists.But having said all this, you told us, that the sessions methodis 'Never' and the entity methods called are 'Supports', so youare right, there should be no transaction at all. And I assume,that, while your tests were running no intentional transactionalmethods were invoked?The last idea I can come up with is: might be you have a typo inyour deployment descriptor where you try to set your methods to'Supports' and thus they are left to the default 'Required'?Checked the CaSe too? I don't know, if this really is verified atdeployment time.If this even isn't the case, I would report this as a possiblebug at SourceForge, as nobody else came into this thread ofdiscussion to help us. Best you would provide more completeserver.log and your relevant deployment descriptor parts and codesamples (i.e. for others to have a true look at case and names ofmethods etc.)Ah, and a final note: the code around the LOCKING-WAITING and theException you receive was just reworked to solve some otherproblem. The modifying author (Bill Burke) said, this only is apartial attempt at the LOCKING-WAITING (he was focused on theother problem, which he solved) issue, but the JBoss founder MarcFleury is just about to rework that code even more.This modification(s) do nothing about the fact, that you seetransactional behaviour, where it shouldn't be (IMHO), but if theabove guess doesn't hold, you still may want to try the newversion out. It's only checked into CVS, so you had to compileJBoss yourself for a test. 4. Yes, conceivably some of the same entity beans are wanted byother threads at the same time as this thread is doing it'sthing. However I thought that, being non-transactional, therewouldn't be any contention problems. Maybe the calls areserialized, but at least there wouldn't be any deadlocks. Am Iwrong? As far as I understand the code version you are executing (2.2.1or 2.2.2 I assume, did you tell us?) there could be deadlock withnon-reentrant beans, at least when they actually do a callback(which would require reentrant to be enabled), but this would belogged differently, so in your case it doesn't seem to be thereason.Just to clarify (my favorite Sequence diagram again :-)sessionentity Aentity B--- I mA1 | | I-->ImB1| I I-->I I I I I ImA2I I II<-I <<< blocks foreverThis is due to a bug (I think) in JBoss in an attempt to be morewise than the EJB Spec, which requires an EJBException to bethrown when B calls back A via mA2 while A still is not finishedwith mA1 and the bean A isn't reentrant. JBoss instead would gointo a busy waiting loop for mA1 to finish, which doesn't happen.But I'm not really sure on this, just haven't the old codearound, and, oops, it's already again 5 a'clock in the morning,much too late to check the old source out and try to verify or doa test case now. If I turn out to be right, I SHOULD report thatas a bug (that code in EntityInstanceInterceptor is really tootricky to fiddle with, when unexperienced)!best regar
Re: More Re: [JBoss-user] When do entity beans commit?
Dear Bryan, > 6. Log messages from server.log - yes this message seemed to > appear many hundred times in a row, around the time of my > deadlock: > > [staffBean] LOCKING-WAITING (TRANSACTION) for id com.theApp.ejb.staffPK@73 > ctx.hash 2702560 tx:TransactionImpl:XidImpl > [FormatId=257, GlobalId=app-web1//188, BranchQual=] This clearly indicates access to an instance INSIDE a transaction that already is associated to another TX. Interesting would be to know if only staffBean with PK 73 is logged, or if other beans are involved/logged, and then which Transaction Global Id is shown there. In a true deadlock scenario you should see one instance logged with (in your case) 73 + app-web1//188 and at least one other with some other PK and Global Id (say 42 + app-web1//4711), in your case I expect both of type staffBean, but in complexer scenarios it could be of some other type. And the true deadlock case could even involve more beans cyclic waiting for each other. If you only see 73 + app-web1//188 LOCKING-WAITING it's more likely, that the instance is participating in a lengthy processing, so that TX app-web1//188 finally gives up, although now true deadlock condition exists. But having said all this, you told us, that the sessions method is 'Never' and the entity methods called are 'Supports', so you are right, there should be no transaction at all. And I assume, that, while your tests were running no intentional transactional methods were invoked? The last idea I can come up with is: might be you have a typo in your deployment descriptor where you try to set your methods to 'Supports' and thus they are left to the default 'Required'? Checked the CaSe too? I don't know, if this really is verified at deployment time. If this even isn't the case, I would report this as a possible bug at SourceForge, as nobody else came into this thread of discussion to help us. Best you would provide more complete server.log and your relevant deployment descriptor parts and code samples (i.e. for others to have a true look at case and names of methods etc.) Ah, and a final note: the code around the LOCKING-WAITING and the Exception you receive was just reworked to solve some other problem. The modifying author (Bill Burke) said, this only is a partial attempt at the LOCKING-WAITING (he was focused on the other problem, which he solved) issue, but the JBoss founder Marc Fleury is just about to rework that code even more. This modification(s) do nothing about the fact, that you see transactional behaviour, where it shouldn't be (IMHO), but if the above guess doesn't hold, you still may want to try the new version out. It's only checked into CVS, so you had to compile JBoss yourself for a test. > 4. Yes, conceivably some of the same entity beans are wanted by > other threads at the same time as this thread is doing it's > thing. However I thought that, being non-transactional, there > wouldn't be any contention problems. Maybe the calls are > serialized, but at least there wouldn't be any deadlocks. Am I > wrong? As far as I understand the code version you are executing (2.2.1 or 2.2.2 I assume, did you tell us?) there could be deadlock with non-reentrant beans, at least when they actually do a callback (which would require reentrant to be enabled), but this would be logged differently, so in your case it doesn't seem to be the reason. Just to clarify (my favorite Sequence diagram again :-) sessionentity Aentity B --- I mA1 | | I-->ImB1| I I-->I I I I I ImA2I I II<-I <<< blocks forever This is due to a bug (I think) in JBoss in an attempt to be more wise than the EJB Spec, which requires an EJBException to be thrown when B calls back A via mA2 while A still is not finished with mA1 and the bean A isn't reentrant. JBoss instead would go into a busy waiting loop for mA1 to finish, which doesn't happen. But I'm not really sure on this, just haven't the old code around, and, oops, it's already again 5 a'clock in the morning, much too late to check the old source out and try to verify or do a test case now. If I turn out to be right, I SHOULD report that as a bug (that code in EntityInstanceInterceptor is really too tricky to fiddle with, when unexperienced)! best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: Bryan, could you please switch to ASCII instead of HTML, it's preferred/required on this list and by me too. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: More Re: [JBoss-user] When do entity beans commit?
Georg, About my environment -- 1. I do not use select...for update 2. Regarding other resources used concurrently -- just entity beans. And as I mentioned -- it's a session bean method marked "Never", which happens to iterate over a large list of entity beans (of several different types) to collect data. The entity beans are marked as "Supports", so as far as I can understand, there should be no transaction occuring. On the entity beans themselves, I'm only calling simple "get" methods (from within this particular session bean method). 3. Regarding lengthy operations -- yes it's sort of lengthy, only a few seconds though. 4. Yes, conceivably some of the same entity beans are wanted by other threads at the same time as this thread is doing it's thing. However I thought that, being non-transactional, there wouldn't be any contention problems. Maybe the calls are serialized, but at least there wouldn't be any deadlocks. Am I wrong? 5. The beans (both session and entity) are non-reentrant. I am not familiar with that setting with respect to EJB and not sure what consequences it would have, or whether I should be investigating it at this time. 6. Log messages from server.log - yes this message seemed to appear many hundred times in a row, around the time of my deadlock: [staffBean] LOCKING-WAITING (TRANSACTION) for id com.theApp.ejb.staffPK@73 ctx.hash 2702560 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=app-web1//188, BranchQual=] Further help would be appreciated Georg, thanks so much for taking the time. Bryan Georg Rehfeld wrote: 02ad01c0f394$5f724e90$[EMAIL PROTECTED]">Hello Bryan, In the scenario in which I describe below, I just got anotherdeadlock error from within a "read-only" method. The transactionexception details are:Name: javax.transaction.TransactionRolledbackExceptionMessage: Transaction marked for rollback, possibly a timeout; nested exception is: (omitted...)I thought that in the below scenario, there are no transactionsat work -- so how could it result in a deadlock, or be rolledback? Help would be appreciated, Difficult to guess from what you tell us. Do you use select forupdate, so that the DB causes deadlocks? Are there otherresources you try to access concurrenty? Is it possible that somebean does lengthy operations (or hangs) while others try toaccess the same bean instance? With non reentrant beans (default)no two clients can enter the same instance concurrently even outside of a transaction.Are there any log messages before theTransactionRolledbackException in the server.log that mightindicate whats going on? Your state charts of I's and dashes are awesome! Actually I tried to draw Sequence Diagrams, I find them helpfulsometimes. What I've done is mark all my Entity beans as "Supports", ratherthan "Requires".Furthermore, at the session bean level, my read-only methods aremarked as "Never", while my read/write methods are marked as"Requires".In this way I get good read-only performance for my read methods,and data integrity for my read/write methods.I am aware that marking my entity beans as "Supports" venturesinto "unspecified" behavior, but in the above scenario, itappears to work in a good way.If I am making a poor assumption here then I would appreciateyour further comments. I think, you do it, as I would have done it, as long as you areaware of the dirty/invalid data status and do not try to modifyanything based on it.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] When do entity beans commit?
Search the archives for isModified. You can perform a straightforward optimization that prevents the unnecessary updates. - Original Message - From: Bryan Field-Elliot To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 2:49 PM Subject: Re: [JBoss-user] When do entity beans commit? Thanks Georg,Your state charts of I's and dashes are awesome!Indeed I no longer saw deadlocks in that scenario, but I did see a performance slowdown, as every single "get" method resulted in the opening and closing of a transaction.What I've done is mark all my Entity beans as "Supports", rather than "Requires".Furthermore, at the session bean level, my read-only methods are marked as "Never", while my read/write methods are marked as "Requires".In this way I get good read-only performance for my read methods, and data integrity for my read/write methods.I am aware that marking my entity beans as "Supports" ventures into "unspecified" behavior, but in the above scenario, it appears to work in a good way.If I am making a poor assumption here then I would appreciate your further comments.Regards,BryanGeorg Rehfeld wrote: 024501c0f36d$c05a1d90$[EMAIL PROTECTED]" type="cite">Hi Bryan, In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)?As of the EJB spec 1.1 section 11.6.2 they are ended on returnfrom the Entities method set to Requires. I crosschecked the codein org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified.session1session2entityA entityB--- ---| I TX.begin | || I-->I || I TX.commit | |I I | TX.begin |I->II I | TX.commit |I I | |I I | TX.begin |I I-->II I | TX.commit |I I TX.begin | |I->I |I I TX.commit | |Thus you should see no deadlock caused.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10- Original Message ----- From: "Bryan Field-Elliot" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Monday, June 11, 2001 11:06 PMSubject: [JBoss-user] When do entity beans commit? I am using jBoss 2.2.2.My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans.All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires".In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional?Help would be appreciated.Regards,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: More Re: [JBoss-user] When do entity beans commit?
Hello Bryan, > In the scenario in which I describe below, I just got another > deadlock error from within a "read-only" method. The transaction > exception details are: > > Name: javax.transaction.TransactionRolledbackException > Message: Transaction marked for rollback, possibly a timeout; > nested exception is: (omitted...) > > I thought that in the below scenario, there are no transactions > at work -- so how could it result in a deadlock, or be rolled > back? Help would be appreciated, Difficult to guess from what you tell us. Do you use select for update, so that the DB causes deadlocks? Are there other resources you try to access concurrenty? Is it possible that some bean does lengthy operations (or hangs) while others try to access the same bean instance? With non reentrant beans (default) no two clients can enter the same instance concurrently even outside of a transaction. Are there any log messages before the TransactionRolledbackException in the server.log that might indicate whats going on? > Your state charts of I's and dashes are awesome! Actually I tried to draw Sequence Diagrams, I find them helpful sometimes. > What I've done is mark all my Entity beans as "Supports", rather > than "Requires". > > Furthermore, at the session bean level, my read-only methods are > marked as "Never", while my read/write methods are marked as > "Requires". > > In this way I get good read-only performance for my read methods, > and data integrity for my read/write methods. > > I am aware that marking my entity beans as "Supports" ventures > into "unspecified" behavior, but in the above scenario, it > appears to work in a good way. > > If I am making a poor assumption here then I would appreciate > your further comments. I think, you do it, as I would have done it, as long as you are aware of the dirty/invalid data status and do not try to modify anything based on it. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
More Re: [JBoss-user] When do entity beans commit?
In the scenario in which I describe below, I just got another deadlock error from within a "read-only" method. The transaction exception details are: Name: javax.transaction.TransactionRolledbackException Message: Transaction marked for rollback, possibly a timeout; nested exception is: (omitted...)I thought that in the below scenario, there are no transactions at work -- so how could it result in a deadlock, or be rolled back?Help would be appreciated,Bryan Bryan Field-Elliot wrote: [EMAIL PROTECTED]"> Thanks Georg, Your state charts of I's and dashes are awesome! Indeed I no longer saw deadlocks in that scenario, but I did see a performance slowdown, as every single "get" method resulted in the opening and closing of a transaction. What I've done is mark all my Entity beans as "Supports", rather than "Requires". Furthermore, at the session bean level, my read-only methods are marked as "Never", while my read/write methods are marked as "Requires". In this way I get good read-only performance for my read methods, and data integrity for my read/write methods. I am aware that marking my entity beans as "Supports" ventures into "unspecified" behavior, but in the above scenario, it appears to work in a good way. If I am making a poor assumption here then I would appreciate your further comments. Regards, Bryan Georg Rehfeld wrote: 024501c0f36d$c05a1d90$[EMAIL PROTECTED]">Hi Bryan, In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? As of the EJB spec 1.1 section 11.6.2 they are ended on returnfrom the Entities method set to Requires. I crosschecked the codein org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified.session1session2entityA entityB--- ---| I TX.begin | || I-->I || I TX.commit | |I I | TX.begin |I->II I | TX.commit |I I | |I I | TX.begin |I I-->II I | TX.commit |I I TX.begin | |I->I |I I TX.commit | |Thus you should see no deadlock caused.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10- Original Message - From: "Bryan Field-Elliot" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Monday, June 11, 2001 11:06 PMSubject: [JBoss-user] When do entity beans commit? I am using jBoss 2.2.2.My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans.All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires".In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional?Help would be appreciated.Regards,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user ___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] When do entity beans commit?
Thanks Georg, Your state charts of I's and dashes are awesome! Indeed I no longer saw deadlocks in that scenario, but I did see a performance slowdown, as every single "get" method resulted in the opening and closing of a transaction. What I've done is mark all my Entity beans as "Supports", rather than "Requires". Furthermore, at the session bean level, my read-only methods are marked as "Never", while my read/write methods are marked as "Requires". In this way I get good read-only performance for my read methods, and data integrity for my read/write methods. I am aware that marking my entity beans as "Supports" ventures into "unspecified" behavior, but in the above scenario, it appears to work in a good way. If I am making a poor assumption here then I would appreciate your further comments. Regards, Bryan Georg Rehfeld wrote: 024501c0f36d$c05a1d90$[EMAIL PROTECTED]">Hi Bryan, In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? As of the EJB spec 1.1 section 11.6.2 they are ended on returnfrom the Entities method set to Requires. I crosschecked the codein org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified.session1session2entityA entityB--- ---| I TX.begin | || I-->I || I TX.commit | |I I | TX.begin |I->II I | TX.commit |I I | |I I | TX.begin |I I-->II I | TX.commit |I I TX.begin | |I->I |I I TX.commit | |Thus you should see no deadlock caused.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10- Original Message - From: "Bryan Field-Elliot" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Monday, June 11, 2001 11:06 PMSubject: [JBoss-user] When do entity beans commit? I am using jBoss 2.2.2.My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans.All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires".In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional?Help would be appreciated.Regards,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user ___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] When do entity beans commit?
Hi Bryan, > In the "Never" session bean methods, when exactly are my entity bean's > transactions ENDED (committed)? As of the EJB spec 1.1 section 11.6.2 they are ended on return from the Entities method set to Requires. I crosschecked the code in org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified. session1session2entityA entityB --- --- | I TX.begin | | | I-->I | | I TX.commit | | I I | TX.begin | I->I I I | TX.commit | I I | | I I | TX.begin | I I-->I I I | TX.commit | I I TX.begin | | I->I | I I TX.commit | | Thus you should see no deadlock caused. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 - Original Message - From: "Bryan Field-Elliot" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 11:06 PM Subject: [JBoss-user] When do entity beans commit? > I am using jBoss 2.2.2. > > My clients access a stateful session bean, and my session bean's methods > in turn access CMP entity beans. > > All my entity beans are marked as "Requires" transactions; in my session > bean, some methods are marked as "Never", while others are marked as > "Requires". > > In the "Never" session bean methods, when exactly are my entity bean's > transactions ENDED (committed)? These are essentially read-only methods > in my session bean. They use entity beans to gather data, but they > aren't making any changes. Nonetheless, they are causing me some > deadlock problems. Will these entity beans not be released until after > my session bean method returns, even though my session bean method is > not transactional? > > Help would be appreciated. > > Regards, > > Bryan > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] When do entity beans commit?
I am using jBoss 2.2.2. My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans. All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires". In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional? Help would be appreciated. Regards, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
