You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jean-Louis MONTEIRO <je...@atosorigin.com> on 2009/08/24 09:53:37 UTC
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache
management issue
Hi David,
Finally, i've got the time to dig into this issue.
This exception occurs when from a session bean you call a SFSB. More
precisely, it's linked with transaction/cache management when the
transaction must be suspended in the stateful.
REQUIRED -> REQUIRES_NEW
REQUIRED -> NOT_SUPPORTED
REQUIRES_NEW-> REQUIRES_NEW
REQUIRES_NEW-> NOT_SUPPORTED
For those cases, the releaseInstance from the StatefulContainer seems to be
called both for JtaTransactionPolicy of the stateful as well as for the
first session bean.
It results in an exception because we try to checkIn the same instance in
the Cache 2 times.
Jean-Louis
David Blevins wrote:
>
> Hi Jean-Louis,
>
> Can't seem to get the time to take a detailed look. Is it possible
> you could give a brief walkthrough of what is happening and the cause?
>
>
> -David
>
>
> On Jul 6, 2009, at 7:03 AM, Monteiro Jean-Louis wrote:
>
>> I change simple-stateless and simple-stateful examples to reproduce
>> this issue.
>>
>> Jean-Louis
>>
>>
>>
>> -----Message d'origine-----
>> De : Jean-Louis MONTEIRO (JIRA) [mailto:jira@apache.org]
>> Envoyé : lundi 6 juillet 2009 16:02
>> À : Monteiro Jean-Louis
>> Objet : [jira] Created: (OPENEJB-1049) Stateful session cache
>> management issue
>>
>> Stateful session cache management issue
>> ---------------------------------------
>>
>> Key: OPENEJB-1049
>> URL: https://issues.apache.org/jira/browse/
>> OPENEJB-1049
>> Project: OpenEJB
>> Issue Type: Bug
>> Affects Versions: 3.1.1
>> Reporter: Jean-Louis MONTEIRO
>>
>>
>> SimpleCache throws an error during check in.
>>
>> ERROR - An unexpected system exception occured while invoking the
>> afterCompletion method on the SessionSynchronization object
>> java.lang.IllegalStateException: The entry
>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>> at
>> org
>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>> 219)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>> 659)
>> at org.apache.openejb.core.stateful.StatefulContainer.access
>> $2(StatefulContainer.java:646)
>> at org.apache.openejb.core.stateful.StatefulContainer
>> $
>> SessionSynchronizationCoordinator
>> .afterCompletion(StatefulContainer.java:940)
>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:326)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>> 245)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .transaction
>> .JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:
>> 291)
>> at
>> org
>> .apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:71)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>> 74)
>> at
>> org
>> .apache
>> .openejb
>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>> 241)
>> at
>> org
>> .apache
>> .openejb
>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:174)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>> 217)
>> at
>> org
>> .apache
>> .openejb
>> .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
>> at
>> org
>> .apache
>> .openejb
>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>> at $Proxy10.sum(Unknown Source)
>> at
>> org
>> .superbiz
>> .calculator
>> .CalculatorTest.testCalculatorViaRemoteInterface(CalculatorTest.java:
>> 51)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:120)
>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>> at junit.framework.TestSuite.run(TestSuite.java:223)
>> at
>> org
>> .junit
>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>> at
>> org
>> .eclipse
>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>> 197)
>> WARN - Unexpected exception from afterCompletion; continuing
>> java.lang.RuntimeException: An unexpected system exception occured
>> while invoking the afterCompletion method on the
>> SessionSynchronization object
>> at org.apache.openejb.core.stateful.StatefulContainer
>> $
>> SessionSynchronizationCoordinator
>> .afterCompletion(StatefulContainer.java:962)
>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:326)
>> at
>> org
>> .apache
>> .geronimo
>> .transaction
>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>> 245)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .transaction
>> .JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:
>> 291)
>> at
>> org
>> .apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:71)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>> 74)
>> at
>> org
>> .apache
>> .openejb
>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>> 241)
>> at
>> org
>> .apache
>> .openejb
>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:174)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>> 217)
>> at
>> org
>> .apache
>> .openejb
>> .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
>> at
>> org
>> .apache
>> .openejb
>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>> at $Proxy10.sum(Unknown Source)
>> at
>> org
>> .superbiz
>> .calculator
>> .CalculatorTest.testCalculatorViaRemoteInterface(CalculatorTest.java:
>> 51)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at junit.framework.TestCase.runTest(TestCase.java:164)
>> at junit.framework.TestCase.runBare(TestCase.java:130)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:120)
>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>> at junit.framework.TestSuite.run(TestSuite.java:223)
>> at
>> org
>> .junit
>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>> at
>> org
>> .eclipse
>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal
>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>> at
>> org
>> .eclipse
>> .jdt
>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>> 197)
>> Caused by: java.lang.IllegalStateException: The entry
>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>> at
>> org
>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>> 219)
>> at
>> org
>> .apache
>> .openejb
>> .core
>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>> 659)
>> at org.apache.openejb.core.stateful.StatefulContainer.access
>> $2(StatefulContainer.java:646)
>> at org.apache.openejb.core.stateful.StatefulContainer
>> $
>> SessionSynchronizationCoordinator
>> .afterCompletion(StatefulContainer.java:940)
>> ... 34 more
>>
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
>>
>> Ce message et les pièces jointes sont confidentiels et réservés à
>> l'usage exclusif de ses destinataires. Il peut également être
>> protégé par le secret professionnel. Si vous recevez ce message par
>> erreur, merci d'en avertir immédiatement l'expéditeur et de le
>> détruire. L'intégrité du message ne pouvant être assurée sur
>> Internet, la responsabilité du groupe Atos Origin ne pourra être
>> recherchée quant au contenu de ce message. Bien que les meilleurs
>> efforts soient faits pour maintenir cette transmission exempte de
>> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>> responsabilité ne saurait être recherchée pour tout dommage
>> résultant d'un virus transmis.
>>
>> This e-mail and the documents attached are confidential and intended
>> solely for the addressee; it may also be privileged. If you receive
>> this e-mail in error, please notify the sender immediately and
>> destroy it. As its integrity cannot be secured on the Internet, the
>> Atos Origin group liability cannot be triggered for the message
>> content. Although the sender endeavours to maintain a computer virus-
>> free network, the sender does not warrant that this transmission is
>> virus-free and will not be liable for any damages resulting from any
>> virus transmitted.
>
>
>
--
View this message in context: http://www.nabble.com/TR%3A--jira--Created%3A-%28OPENEJB-1049%29-Stateful-session-cache-management-issue-tp24356051p25111942.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache management issue
Posted by David Blevins <da...@visi.com>.
On Sep 1, 2009, at 8:33 PM, David Blevins wrote:
> Been looking into this one and not too sure how we want to deal with
> it. We definitely want to fix it for our 3.1.2 release. I've had a
> look at our 3.0.x logic and we do allow this scenario though the
> spec sort of says it should result in an "error" though never says
> what the error should be. I like the 3.0.x behavior of allowing
> someone executing a stateful bean in a transaction to pause the
> transaction and still be able to use the stateful bean.
>
> We've had 3.1.x out for a while but 3.1.2 will be Geronimo's first
> release since 3.0.x so this could pose a compatibility issue for
> users upgrading -- I can't imagine anyone being too happy about
> having to rewrite transaction logic.
>
> Racking my brain on how best to fix this.
Went back at this issue the last couple days and it's looking to be
very difficult to retain the behavior we had in 3.0 with the way the
new code is written.
Having dug deeper into the issue the problem is not with the
SimpleCache code but rather asymmetry in the obtainInstance() and
releaseInstance() methods. Specifically, the checkedOutInstances map
and related code which is getting used as a secondary cache and isn't
well managed. There are other issues with the code such as it is
possible for another thread outside your to remove your stateful
instance. That's a rather big no-no as lots of stateful code is
designed to flush data in the beforeCompletion() and well, you need
the instance for that. Basically, the current code protects against
the instance being used by multiple threads at the same time, but does
not protect against it being used by multiple transactions at the same
time.
Going to keep hacking on it tomorrow.
-David
>
> -David
>
> On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
>
>>
>> Hi David,
>>
>> Finally, i've got the time to dig into this issue.
>> This exception occurs when from a session bean you call a SFSB. More
>> precisely, it's linked with transaction/cache management when the
>> transaction must be suspended in the stateful.
>>
>> REQUIRED -> REQUIRES_NEW
>> REQUIRED -> NOT_SUPPORTED
>> REQUIRES_NEW-> REQUIRES_NEW
>> REQUIRES_NEW-> NOT_SUPPORTED
>>
>> For those cases, the releaseInstance from the StatefulContainer
>> seems to be
>> called both for JtaTransactionPolicy of the stateful as well as for
>> the
>> first session bean.
>>
>> It results in an exception because we try to checkIn the same
>> instance in
>> the Cache 2 times.
>>
>> Jean-Louis
>>
>>
>>
>> David Blevins wrote:
>>>
>>> Hi Jean-Louis,
>>>
>>> Can't seem to get the time to take a detailed look. Is it possible
>>> you could give a brief walkthrough of what is happening and the
>>> cause?
>>>
>>>
>>> -David
>>>
>>>
>>> On Jul 6, 2009, at 7:03 AM, Monteiro Jean-Louis wrote:
>>>
>>>> I change simple-stateless and simple-stateful examples to reproduce
>>>> this issue.
>>>>
>>>> Jean-Louis
>>>>
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : Jean-Louis MONTEIRO (JIRA) [mailto:jira@apache.org]
>>>> Envoyé : lundi 6 juillet 2009 16:02
>>>> À : Monteiro Jean-Louis
>>>> Objet : [jira] Created: (OPENEJB-1049) Stateful session cache
>>>> management issue
>>>>
>>>> Stateful session cache management issue
>>>> ---------------------------------------
>>>>
>>>> Key: OPENEJB-1049
>>>> URL: https://issues.apache.org/jira/browse/
>>>> OPENEJB-1049
>>>> Project: OpenEJB
>>>> Issue Type: Bug
>>>> Affects Versions: 3.1.1
>>>> Reporter: Jean-Louis MONTEIRO
>>>>
>>>>
>>>> SimpleCache throws an error during check in.
>>>>
>>>> ERROR - An unexpected system exception occured while invoking the
>>>> afterCompletion method on the SessionSynchronization object
>>>> java.lang.IllegalStateException: The entry
>>>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>>>> at
>>>> org
>>>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>>>> 219)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>>>> 659)
>>>> at org.apache.openejb.core.stateful.StatefulContainer.access
>>>> $2(StatefulContainer.java:646)
>>>> at org.apache.openejb.core.stateful.StatefulContainer
>>>> $
>>>> SessionSynchronizationCoordinator
>>>> .afterCompletion(StatefulContainer.java:940)
>>>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>>>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:
>>>> 326)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>>>> 245)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .transaction
>>>> .JtaTransactionPolicy
>>>> .completeTransaction(JtaTransactionPolicy.java:
>>>> 291)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb.core.transaction.TxRequired.commit(TxRequired.java:71)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .transaction
>>>> .EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>>>> 74)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>>>> 241)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:
>>>> 174)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .ivm
>>>> .EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>>>> 217)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>>>> at $Proxy10.sum(Unknown Source)
>>>> at
>>>> org
>>>> .superbiz
>>>> .calculator
>>>> .CalculatorTest
>>>> .testCalculatorViaRemoteInterface(CalculatorTest.java:
>>>> 51)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingMethodAccessorImpl
>>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>>> 128)
>>>> at junit.framework.TestResult.run(TestResult.java:113)
>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>>>> at junit.framework.TestSuite.run(TestSuite.java:223)
>>>> at
>>>> org
>>>> .junit
>>>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:
>>>> 35)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>>> 390)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>> 197)
>>>> WARN - Unexpected exception from afterCompletion; continuing
>>>> java.lang.RuntimeException: An unexpected system exception occured
>>>> while invoking the afterCompletion method on the
>>>> SessionSynchronization object
>>>> at org.apache.openejb.core.stateful.StatefulContainer
>>>> $
>>>> SessionSynchronizationCoordinator
>>>> .afterCompletion(StatefulContainer.java:962)
>>>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>>>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:
>>>> 326)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .transaction
>>>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>>>> 245)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .transaction
>>>> .JtaTransactionPolicy
>>>> .completeTransaction(JtaTransactionPolicy.java:
>>>> 291)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb.core.transaction.TxRequired.commit(TxRequired.java:71)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .transaction
>>>> .EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>>>> 74)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>>>> 241)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:
>>>> 174)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .ivm
>>>> .EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>>>> 217)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>>>> at $Proxy10.sum(Unknown Source)
>>>> at
>>>> org
>>>> .superbiz
>>>> .calculator
>>>> .CalculatorTest
>>>> .testCalculatorViaRemoteInterface(CalculatorTest.java:
>>>> 51)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingMethodAccessorImpl
>>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>>> 128)
>>>> at junit.framework.TestResult.run(TestResult.java:113)
>>>> at junit.framework.TestCase.run(TestCase.java:120)
>>>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>>>> at junit.framework.TestSuite.run(TestSuite.java:223)
>>>> at
>>>> org
>>>> .junit
>>>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:
>>>> 35)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal
>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>>> 390)
>>>> at
>>>> org
>>>> .eclipse
>>>> .jdt
>>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>>> 197)
>>>> Caused by: java.lang.IllegalStateException: The entry
>>>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>>>> at
>>>> org
>>>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>>>> 219)
>>>> at
>>>> org
>>>> .apache
>>>> .openejb
>>>> .core
>>>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>>>> 659)
>>>> at org.apache.openejb.core.stateful.StatefulContainer.access
>>>> $2(StatefulContainer.java:646)
>>>> at org.apache.openejb.core.stateful.StatefulContainer
>>>> $
>>>> SessionSynchronizationCoordinator
>>>> .afterCompletion(StatefulContainer.java:940)
>>>> ... 34 more
>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>>
>>>>
>>>> Ce message et les pièces jointes sont confidentiels et réservés à
>>>> l'usage exclusif de ses destinataires. Il peut également être
>>>> protégé par le secret professionnel. Si vous recevez ce message par
>>>> erreur, merci d'en avertir immédiatement l'expéditeur et de le
>>>> détruire. L'intégrité du message ne pouvant être assurée sur
>>>> Internet, la responsabilité du groupe Atos Origin ne pourra être
>>>> recherchée quant au contenu de ce message. Bien que les meilleurs
>>>> efforts soient faits pour maintenir cette transmission exempte de
>>>> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>>>> responsabilité ne saurait être recherchée pour tout dommage
>>>> résultant d'un virus transmis.
>>>>
>>>> This e-mail and the documents attached are confidential and
>>>> intended
>>>> solely for the addressee; it may also be privileged. If you receive
>>>> this e-mail in error, please notify the sender immediately and
>>>> destroy it. As its integrity cannot be secured on the Internet, the
>>>> Atos Origin group liability cannot be triggered for the message
>>>> content. Although the sender endeavours to maintain a computer
>>>> virus-
>>>> free network, the sender does not warrant that this transmission is
>>>> virus-free and will not be liable for any damages resulting from
>>>> any
>>>> virus transmitted.
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/TR%3A--jira--Created%3A-%28OPENEJB-1049%29-Stateful-session-cache-management-issue-tp24356051p25111942.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>>
>
>
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache management issue
Posted by David Blevins <da...@visi.com>.
Been looking into this one and not too sure how we want to deal with
it. We definitely want to fix it for our 3.1.2 release. I've had a
look at our 3.0.x logic and we do allow this scenario though the spec
sort of says it should result in an "error" though never says what the
error should be. I like the 3.0.x behavior of allowing someone
executing a stateful bean in a transaction to pause the transaction
and still be able to use the stateful bean.
We've had 3.1.x out for a while but 3.1.2 will be Geronimo's first
release since 3.0.x so this could pose a compatibility issue for users
upgrading -- I can't imagine anyone being too happy about having to
rewrite transaction logic.
Racking my brain on how best to fix this.
-David
On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
>
> Hi David,
>
> Finally, i've got the time to dig into this issue.
> This exception occurs when from a session bean you call a SFSB. More
> precisely, it's linked with transaction/cache management when the
> transaction must be suspended in the stateful.
>
> REQUIRED -> REQUIRES_NEW
> REQUIRED -> NOT_SUPPORTED
> REQUIRES_NEW-> REQUIRES_NEW
> REQUIRES_NEW-> NOT_SUPPORTED
>
> For those cases, the releaseInstance from the StatefulContainer
> seems to be
> called both for JtaTransactionPolicy of the stateful as well as for
> the
> first session bean.
>
> It results in an exception because we try to checkIn the same
> instance in
> the Cache 2 times.
>
> Jean-Louis
>
>
>
> David Blevins wrote:
>>
>> Hi Jean-Louis,
>>
>> Can't seem to get the time to take a detailed look. Is it possible
>> you could give a brief walkthrough of what is happening and the
>> cause?
>>
>>
>> -David
>>
>>
>> On Jul 6, 2009, at 7:03 AM, Monteiro Jean-Louis wrote:
>>
>>> I change simple-stateless and simple-stateful examples to reproduce
>>> this issue.
>>>
>>> Jean-Louis
>>>
>>>
>>>
>>> -----Message d'origine-----
>>> De : Jean-Louis MONTEIRO (JIRA) [mailto:jira@apache.org]
>>> Envoyé : lundi 6 juillet 2009 16:02
>>> À : Monteiro Jean-Louis
>>> Objet : [jira] Created: (OPENEJB-1049) Stateful session cache
>>> management issue
>>>
>>> Stateful session cache management issue
>>> ---------------------------------------
>>>
>>> Key: OPENEJB-1049
>>> URL: https://issues.apache.org/jira/browse/
>>> OPENEJB-1049
>>> Project: OpenEJB
>>> Issue Type: Bug
>>> Affects Versions: 3.1.1
>>> Reporter: Jean-Louis MONTEIRO
>>>
>>>
>>> SimpleCache throws an error during check in.
>>>
>>> ERROR - An unexpected system exception occured while invoking the
>>> afterCompletion method on the SessionSynchronization object
>>> java.lang.IllegalStateException: The entry
>>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>>> at
>>> org
>>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>>> 219)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>>> 659)
>>> at org.apache.openejb.core.stateful.StatefulContainer.access
>>> $2(StatefulContainer.java:646)
>>> at org.apache.openejb.core.stateful.StatefulContainer
>>> $
>>> SessionSynchronizationCoordinator
>>> .afterCompletion(StatefulContainer.java:940)
>>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:
>>> 326)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>>> 245)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .transaction
>>> .JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:
>>> 291)
>>> at
>>> org
>>> .apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:
>>> 71)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>>> 74)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>>> 241)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:
>>> 174)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .ivm
>>> .EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>>> 217)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:
>>> 77)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>>> at $Proxy10.sum(Unknown Source)
>>> at
>>> org
>>> .superbiz
>>> .calculator
>>> .CalculatorTest
>>> .testCalculatorViaRemoteInterface(CalculatorTest.java:
>>> 51)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl
>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>> 128)
>>> at junit.framework.TestResult.run(TestResult.java:113)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>>> at junit.framework.TestSuite.run(TestSuite.java:223)
>>> at
>>> org
>>> .junit
>>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>>> at
>>> org
>>> .eclipse
>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>> 390)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>> 197)
>>> WARN - Unexpected exception from afterCompletion; continuing
>>> java.lang.RuntimeException: An unexpected system exception occured
>>> while invoking the afterCompletion method on the
>>> SessionSynchronization object
>>> at org.apache.openejb.core.stateful.StatefulContainer
>>> $
>>> SessionSynchronizationCoordinator
>>> .afterCompletion(StatefulContainer.java:962)
>>> at org.apache.openejb.core.transaction.JtaTransactionPolicy
>>> $1.afterCompletion(JtaTransactionPolicy.java:155)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:534)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionImpl.afterCompletion(TransactionImpl.java:526)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction.manager.TransactionImpl.commit(TransactionImpl.java:
>>> 326)
>>> at
>>> org
>>> .apache
>>> .geronimo
>>> .transaction
>>> .manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:
>>> 245)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .transaction
>>> .JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:
>>> 291)
>>> at
>>> org
>>> .apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:
>>> 71)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:
>>> 74)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.stateless.StatelessContainer._invoke(StatelessContainer.java:
>>> 241)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.stateless.StatelessContainer.invoke(StatelessContainer.java:
>>> 174)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .ivm
>>> .EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:
>>> 217)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:
>>> 77)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
>>> at $Proxy10.sum(Unknown Source)
>>> at
>>> org
>>> .superbiz
>>> .calculator
>>> .CalculatorTest
>>> .testCalculatorViaRemoteInterface(CalculatorTest.java:
>>> 51)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl
>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>> 128)
>>> at junit.framework.TestResult.run(TestResult.java:113)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:228)
>>> at junit.framework.TestSuite.run(TestSuite.java:223)
>>> at
>>> org
>>> .junit
>>> .internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>>> at
>>> org
>>> .eclipse
>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>> 390)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:
>>> 197)
>>> Caused by: java.lang.IllegalStateException: The entry
>>> d52b726a0e36ac50:-3f5aa6df:122503062bb:-8000 is not checked-out
>>> at
>>> org
>>> .apache.openejb.core.stateful.SimpleCache.checkIn(SimpleCache.java:
>>> 219)
>>> at
>>> org
>>> .apache
>>> .openejb
>>> .core
>>> .stateful.StatefulContainer.releaseInstance(StatefulContainer.java:
>>> 659)
>>> at org.apache.openejb.core.stateful.StatefulContainer.access
>>> $2(StatefulContainer.java:646)
>>> at org.apache.openejb.core.stateful.StatefulContainer
>>> $
>>> SessionSynchronizationCoordinator
>>> .afterCompletion(StatefulContainer.java:940)
>>> ... 34 more
>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>>
>>>
>>> Ce message et les pièces jointes sont confidentiels et réservés à
>>> l'usage exclusif de ses destinataires. Il peut également être
>>> protégé par le secret professionnel. Si vous recevez ce message par
>>> erreur, merci d'en avertir immédiatement l'expéditeur et de le
>>> détruire. L'intégrité du message ne pouvant être assurée sur
>>> Internet, la responsabilité du groupe Atos Origin ne pourra être
>>> recherchée quant au contenu de ce message. Bien que les meilleurs
>>> efforts soient faits pour maintenir cette transmission exempte de
>>> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>>> responsabilité ne saurait être recherchée pour tout dommage
>>> résultant d'un virus transmis.
>>>
>>> This e-mail and the documents attached are confidential and intended
>>> solely for the addressee; it may also be privileged. If you receive
>>> this e-mail in error, please notify the sender immediately and
>>> destroy it. As its integrity cannot be secured on the Internet, the
>>> Atos Origin group liability cannot be triggered for the message
>>> content. Although the sender endeavours to maintain a computer
>>> virus-
>>> free network, the sender does not warrant that this transmission is
>>> virus-free and will not be liable for any damages resulting from any
>>> virus transmitted.
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/TR%3A--jira--Created%3A-%28OPENEJB-1049%29-Stateful-session-cache-management-issue-tp24356051p25111942.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
>
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache
management issue
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Awesome.
Great job David.
Thanks a lot for that.
I gonna have a look and test it now.
Jean-Louis
David Blevins wrote:
>
> On Sep 25, 2009, at 5:20 PM, David Blevins wrote:
>
>>
>> On Sep 24, 2009, at 2:27 PM, David Blevins wrote:
>>
>>>
>>> On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
>>>
>>>> REQUIRED -> REQUIRES_NEW
>>>> REQUIRED -> NOT_SUPPORTED
>>>
>>> Hey Jean-Louis, do you think you'll need the REQUIRED ->
>>> REQUIRES_NEW scenario? Technically neither of the above is legal
>>> or portable, but I think we can support REQUIRED->NOT_SUPPORTED
>>> just fine, but the other may be a tricky rule to bend code wise.
>>>
>>> The code I'm working on now associates a Transaction with the
>>> o.a.o.core.stateful.Instance object (basically a new field) and
>>> uses that to determine if you are attempting to use the instance
>>> outside the transaction. Going from a transaction state to a non
>>> transaction state is doable. Going from a transaction state to
>>> another transaction state (essentially an nested transaction) would
>>> require a bit of fanciness.
>>
>> Grr. Got something that works, but now am running into an issue
>> with one of the more obscure restrictions that you can't remove a
>> bean via its EJBObject or EJBHome interface if it is in a
>> transaction. It's breaking one of our tests and I know it will
>> break the TCK.
>>
>
> Alright, we're good on this one now.
>
> We now track a transaction object in the Instance which is checked to
> prevent access outside the transaction. It's actually a stack of
> Transaction objects.. more on that next.
>
> We also have some special logic that allows the client using the
> instance in the transaction to bend the rules and invoke the bean as
> it wishes (it can still invoke REQUIRES_NEW and NOT_SUPPORTED
> methods). In this scenario the instance will still be considered in
> transaction stay locked to other threads.
>
> Going to push new snapshots. On the Geronimo side we'll want to kick
> off a new tck run. If that looks good, we can finally cut this release.
>
>
> -David
>
>
>
--
View this message in context: http://www.nabble.com/TR%3A--jira--Created%3A-%28OPENEJB-1049%29-Stateful-session-cache-management-issue-tp24356051p25657850.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache management issue
Posted by David Blevins <da...@visi.com>.
On Sep 25, 2009, at 5:20 PM, David Blevins wrote:
>
> On Sep 24, 2009, at 2:27 PM, David Blevins wrote:
>
>>
>> On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
>>
>>> REQUIRED -> REQUIRES_NEW
>>> REQUIRED -> NOT_SUPPORTED
>>
>> Hey Jean-Louis, do you think you'll need the REQUIRED ->
>> REQUIRES_NEW scenario? Technically neither of the above is legal
>> or portable, but I think we can support REQUIRED->NOT_SUPPORTED
>> just fine, but the other may be a tricky rule to bend code wise.
>>
>> The code I'm working on now associates a Transaction with the
>> o.a.o.core.stateful.Instance object (basically a new field) and
>> uses that to determine if you are attempting to use the instance
>> outside the transaction. Going from a transaction state to a non
>> transaction state is doable. Going from a transaction state to
>> another transaction state (essentially an nested transaction) would
>> require a bit of fanciness.
>
> Grr. Got something that works, but now am running into an issue
> with one of the more obscure restrictions that you can't remove a
> bean via its EJBObject or EJBHome interface if it is in a
> transaction. It's breaking one of our tests and I know it will
> break the TCK.
>
Alright, we're good on this one now.
We now track a transaction object in the Instance which is checked to
prevent access outside the transaction. It's actually a stack of
Transaction objects.. more on that next.
We also have some special logic that allows the client using the
instance in the transaction to bend the rules and invoke the bean as
it wishes (it can still invoke REQUIRES_NEW and NOT_SUPPORTED
methods). In this scenario the instance will still be considered in
transaction stay locked to other threads.
Going to push new snapshots. On the Geronimo side we'll want to kick
off a new tck run. If that looks good, we can finally cut this release.
-David
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache management issue
Posted by David Blevins <da...@visi.com>.
On Sep 24, 2009, at 2:27 PM, David Blevins wrote:
>
> On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
>
>> REQUIRED -> REQUIRES_NEW
>> REQUIRED -> NOT_SUPPORTED
>
> Hey Jean-Louis, do you think you'll need the REQUIRED ->
> REQUIRES_NEW scenario? Technically neither of the above is legal
> or portable, but I think we can support REQUIRED->NOT_SUPPORTED just
> fine, but the other may be a tricky rule to bend code wise.
>
> The code I'm working on now associates a Transaction with the
> o.a.o.core.stateful.Instance object (basically a new field) and uses
> that to determine if you are attempting to use the instance outside
> the transaction. Going from a transaction state to a non
> transaction state is doable. Going from a transaction state to
> another transaction state (essentially an nested transaction) would
> require a bit of fanciness.
Grr. Got something that works, but now am running into an issue with
one of the more obscure restrictions that you can't remove a bean via
its EJBObject or EJBHome interface if it is in a transaction. It's
breaking one of our tests and I know it will break the TCK.
Still hacking.
-David
Re: TR: [jira] Created: (OPENEJB-1049) Stateful session cache management issue
Posted by David Blevins <da...@visi.com>.
On Aug 24, 2009, at 12:53 AM, Jean-Louis MONTEIRO wrote:
> REQUIRED -> REQUIRES_NEW
> REQUIRED -> NOT_SUPPORTED
Hey Jean-Louis, do you think you'll need the REQUIRED -> REQUIRES_NEW
scenario? Technically neither of the above is legal or portable, but
I think we can support REQUIRED->NOT_SUPPORTED just fine, but the
other may be a tricky rule to bend code wise.
The code I'm working on now associates a Transaction with the
o.a.o.core.stateful.Instance object (basically a new field) and uses
that to determine if you are attempting to use the instance outside
the transaction. Going from a transaction state to a non transaction
state is doable. Going from a transaction state to another
transaction state (essentially an nested transaction) would require a
bit of fanciness.
-David