You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by John Ament <my...@gmail.com> on 2009/12/14 11:47:57 UTC
Re: transaction rolls back when returning from a remove method of a
SFSB
What you're describing is exactly what's supposed to be happening. You're
not supposed to invoke the @Remove method from your own code. When the bean
container passivates the instance, it calls @Remove for you.
On Mon, Dec 14, 2009 at 5:13 AM, is_maximum <mn...@gmail.com> wrote:
>
> Hello
> I have a Stateful session bean with three method preProcess, process and
> postProcess. the postProcess method marked with @Remove
> these three methods are called in one method of a stateless session bean.
> After calling the postProcess the transaction will mark to rollback. I put
> a
> bunch of System.out to pring out getRollbackOnly() of the session context
> and I am sure no exception occured. At the point just before returning from
> postProcess the log shows the getRollbackOnly() is false but in callee
> method right after this method invocation getRollbackOnly() is true!!!!
>
> Does anybody know what the problem is?
>
> Furthermore, When I comment out the @Remove annotation the whole
> transaction
> works fine but I don't know what will happen on the deserted stateful
> session bean which is not destroyed manually!
>
> [code]
> class MyStatefullSB {
> @Remove
> public void postProcess() {
> ....
> logger.debug(sc.getRollbackOnly()); //prints out false
> }
>
> }
>
> class MyStatelessSB {
>
> public void someMethod() {
>
> mystateful.preProcess();
> mystateful.process();
> mystateful.postProcess();
> logger.debug(sc.getRollbackOnly()); //prints out true!!!!
> }
> }
> [/code]
>
>
> -----
> --
> Regards
>
> Mohammad Norouzi
>
> Help each other to reach the future faster
>
> http://pixelshot.wordpress.com Pixelshot Photoblog
>
> http://brainable.blogspot.com Brainable Blog
>
>
> --
> View this message in context:
> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp26775547p26775547.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: transaction rolls back when returning from a remove method of a SFSB
Posted by David Blevins <da...@visi.com>.
On Dec 30, 2009, at 4:25 PM, is_maximum wrote:
>
> Hi Jean Louis,
> Currently we are using OpenEJB v3.1.1 but I don't think this is the
> case
> because in our app server (GlassFish) the problem exists as well.
>
> Anyway, I will try with the version 3.1.2 that you stated and I will
> give
> the feedback.
Definitely try this with 3.1.2 and let us know how it goes. I'd like
to look into this, but we did have some work that went into
transaction handling with regards to nesting and exception handling
between 3.1.1 and 3.1.2 which could have a very direct impact on this.
-David
>
> Jean-Louis MONTEIRO wrote:
>>
>> Hi Mohammad,
>>
>> Can you provide the OpenEJB version please?
>> There was a bug in transaction management for stateful beans.
>>
>> It was fixed in 3.1.2. Can you give it a try?
>>
>> Jean-Louis
>>
>>
>> is_maximum wrote:
>>>
>>> Thanks John, You said if this happens it seems that you do
>>> something that
>>> is not allowed in the @Remove method but I add another method say
>>> remove() with no body and no return value and just mark it as
>>> @Remove but
>>> still the same problem exists.
>>>
>>> I also monitored the pool and cache of app server to see what
>>> happens if
>>> I don't call remove method and unfortunately each request I send
>>> that
>>> session beans remains in cache and in method-ready state for a
>>> long time
>>> (the time as set to be expired in app server configuration) and
>>> this is
>>> reallt bad!! This application is a banking system and the
>>> performance is
>>> highly required!
>>>
>>>
>>>
>>> John Ament wrote:
>>>>
>>>> I'm not disputing that part, remove is meant to say "Ok, I don't
>>>> need
>>>> this
>>>> bean anymore." But it may be a case of something in the code
>>>> that's in
>>>> your
>>>> remove is messing with the state of the bean. Since you can call
>>>> it
>>>> fine
>>>> without the @Remove, the only likely scenario is that you're doing
>>>> something
>>>> that's not allowed in the @Remove method, but I honestly can't
>>>> think of
>>>> anything that falls into that scenario.
>>>>
>>>> -----Original Message-----
>>>> From: is_maximum [mailto:mnrz57@gmail.com]
>>>> Sent: Saturday, December 19, 2009 12:31 AM
>>>> To: users@openejb.apache.org
>>>> Subject: Re: transaction rolls back when returning from a remove
>>>> method
>>>> of a
>>>> SFSB
>>>>
>>>>
>>>> Hi
>>>> As far as I understood from this document and EJB3 spec. if the
>>>> client
>>>> doesn't invoke the remove method, that instance wont be
>>>> availablable for
>>>> any
>>>> other request and will be passivated until its timeout reaches
>>>> and then
>>>> the
>>>> container will remove it and this has performance issues and we
>>>> have to
>>>> call
>>>> remove method so release resources.
>>>> I hope David can shed some light on this
>>>>
>>>>
>>>> meetoblivion wrote:
>>>>>
>>>>> Sorry was thinking of Passivate/Activate
>>>>>
>>>>> Here's the more up to date docs:
>>>>>
>>>>> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>>>>>
>>>>> <http://java.sun.com/javaee/5/docs/tutorial/doc/
>>>>> bnbmt.html#bnbmu>I'm
>>>>> curious
>>>>> to know what it is you're doing in postProcess, I'm still
>>>>> inclined to
>>>>> say
>>>>> that it's behaving correctly but it depends on what you're doing
>>>>> in
>>>>> there.
>>>>>
>>>>> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> meetoblivion wrote:
>>>>>>>
>>>>>>> What you're describing is exactly what's supposed to be
>>>>>>> happening.
>>>>>> You're
>>>>>>> not supposed to invoke the @Remove method from your own code.
>>>>>>> When
>>>>>> the
>>>>>>> bean
>>>>>>> container passivates the instance, it calls @Remove for you.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>> As far as I know, it is the client that invokes the remove
>>>>>> method and
>>>>>> if
>>>>>> the
>>>>>> container passivates the SFSB the session bean will not reset its
>>>>>> state
>>>>>>
>>>>>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> --
>>>>>> Regards
>>>>>>
>>>>>> Mohammad Norouzi
>>>>>>
>>>>>> Help each other to reach the future faster
>>>>>>
>>>>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>>>>
>>>>>> http://brainable.blogspot.com Brainable Blog
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>>>> thod-of-a-SFSB-tp26775547p26779956.html
>>>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -----
>>>> --
>>>> Regards
>>>>
>>>> Mohammad Norouzi
>>>>
>>>> Help each other to reach the future faster
>>>>
>>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>>
>>>> http://brainable.blogspot.com Brainable Blog
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>>>> thod-of-a-SFSB-tp26775547p26852910.html
>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date:
>>>> 12/18/09
>>>> 19:38:00
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> -----
> --
> Regards
> Mohammad
> http://pixelshot.wordpress.com Pixelshot
> --
> View this message in context: http://n4.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp979527p990971.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
RE: transaction rolls back when returning from a remove method of a
SFSB
Posted by is_maximum <mn...@gmail.com>.
Hi Jean Louis,
Currently we are using OpenEJB v3.1.1 but I don't think this is the case
because in our app server (GlassFish) the problem exists as well.
Anyway, I will try with the version 3.1.2 that you stated and I will give
the feedback.
Thanks
Jean-Louis MONTEIRO wrote:
>
> Hi Mohammad,
>
> Can you provide the OpenEJB version please?
> There was a bug in transaction management for stateful beans.
>
> It was fixed in 3.1.2. Can you give it a try?
>
> Jean-Louis
>
>
> is_maximum wrote:
>>
>> Thanks John, You said if this happens it seems that you do something that
>> is not allowed in the @Remove method but I add another method say
>> remove() with no body and no return value and just mark it as @Remove but
>> still the same problem exists.
>>
>> I also monitored the pool and cache of app server to see what happens if
>> I don't call remove method and unfortunately each request I send that
>> session beans remains in cache and in method-ready state for a long time
>> (the time as set to be expired in app server configuration) and this is
>> reallt bad!! This application is a banking system and the performance is
>> highly required!
>>
>>
>>
>> John Ament wrote:
>>>
>>> I'm not disputing that part, remove is meant to say "Ok, I don't need
>>> this
>>> bean anymore." But it may be a case of something in the code that's in
>>> your
>>> remove is messing with the state of the bean. Since you can call it
>>> fine
>>> without the @Remove, the only likely scenario is that you're doing
>>> something
>>> that's not allowed in the @Remove method, but I honestly can't think of
>>> anything that falls into that scenario.
>>>
>>> -----Original Message-----
>>> From: is_maximum [mailto:mnrz57@gmail.com]
>>> Sent: Saturday, December 19, 2009 12:31 AM
>>> To: users@openejb.apache.org
>>> Subject: Re: transaction rolls back when returning from a remove method
>>> of a
>>> SFSB
>>>
>>>
>>> Hi
>>> As far as I understood from this document and EJB3 spec. if the client
>>> doesn't invoke the remove method, that instance wont be availablable for
>>> any
>>> other request and will be passivated until its timeout reaches and then
>>> the
>>> container will remove it and this has performance issues and we have to
>>> call
>>> remove method so release resources.
>>> I hope David can shed some light on this
>>>
>>>
>>> meetoblivion wrote:
>>>>
>>>> Sorry was thinking of Passivate/Activate
>>>>
>>>> Here's the more up to date docs:
>>>>
>>>> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>>>>
>>>> <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm
>>>> curious
>>>> to know what it is you're doing in postProcess, I'm still inclined to
>>>> say
>>>> that it's behaving correctly but it depends on what you're doing in
>>>> there.
>>>>
>>>> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> meetoblivion wrote:
>>>>> >
>>>>> > What you're describing is exactly what's supposed to be happening.
>>>>> You're
>>>>> > not supposed to invoke the @Remove method from your own code. When
>>>>> the
>>>>> > bean
>>>>> > container passivates the instance, it calls @Remove for you.
>>>>> >
>>>>> >
>>>>>
>>>>> Thanks.
>>>>> As far as I know, it is the client that invokes the remove method and
>>>>> if
>>>>> the
>>>>> container passivates the SFSB the session bean will not reset its
>>>>> state
>>>>>
>>>>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> --
>>>>> Regards
>>>>>
>>>>> Mohammad Norouzi
>>>>>
>>>>> Help each other to reach the future faster
>>>>>
>>>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>>>
>>>>> http://brainable.blogspot.com Brainable Blog
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>>> thod-of-a-SFSB-tp26775547p26779956.html
>>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> --
>>> Regards
>>>
>>> Mohammad Norouzi
>>>
>>> Help each other to reach the future faster
>>>
>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>
>>> http://brainable.blogspot.com Brainable Blog
>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>>> thod-of-a-SFSB-tp26775547p26852910.html
>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date:
>>> 12/18/09
>>> 19:38:00
>>>
>>>
>>>
>>
>>
>
>
-----
--
Regards
Mohammad
http://pixelshot.wordpress.com Pixelshot
--
View this message in context: http://n4.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp979527p990971.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: transaction rolls back when returning from a remove method of a
SFSB
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi Mohammad,
Can you provide the OpenEJB version please?
There was a bug in transaction management for stateful beans.
It was fixed in 3.1.2. Can you give it a try?
Jean-Louis
is_maximum wrote:
>
> Thanks John, You said if this happens it seems that you do something that
> is not allowed in the @Remove method but I add another method say remove()
> with no body and no return value and just mark it as @Remove but still the
> same problem exists.
>
> I also monitored the pool and cache of app server to see what happens if I
> don't call remove method and unfortunately each request I send that
> session beans remains in cache and in method-ready state for a long time
> (the time as set to be expired in app server configuration) and this is
> reallt bad!! This application is a banking system and the performance is
> highly required!
>
>
>
> John Ament wrote:
>>
>> I'm not disputing that part, remove is meant to say "Ok, I don't need
>> this
>> bean anymore." But it may be a case of something in the code that's in
>> your
>> remove is messing with the state of the bean. Since you can call it fine
>> without the @Remove, the only likely scenario is that you're doing
>> something
>> that's not allowed in the @Remove method, but I honestly can't think of
>> anything that falls into that scenario.
>>
>> -----Original Message-----
>> From: is_maximum [mailto:mnrz57@gmail.com]
>> Sent: Saturday, December 19, 2009 12:31 AM
>> To: users@openejb.apache.org
>> Subject: Re: transaction rolls back when returning from a remove method
>> of a
>> SFSB
>>
>>
>> Hi
>> As far as I understood from this document and EJB3 spec. if the client
>> doesn't invoke the remove method, that instance wont be availablable for
>> any
>> other request and will be passivated until its timeout reaches and then
>> the
>> container will remove it and this has performance issues and we have to
>> call
>> remove method so release resources.
>> I hope David can shed some light on this
>>
>>
>> meetoblivion wrote:
>>>
>>> Sorry was thinking of Passivate/Activate
>>>
>>> Here's the more up to date docs:
>>>
>>> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>>>
>>> <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm
>>> curious
>>> to know what it is you're doing in postProcess, I'm still inclined to
>>> say
>>> that it's behaving correctly but it depends on what you're doing in
>>> there.
>>>
>>> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> meetoblivion wrote:
>>>> >
>>>> > What you're describing is exactly what's supposed to be happening.
>>>> You're
>>>> > not supposed to invoke the @Remove method from your own code. When
>>>> the
>>>> > bean
>>>> > container passivates the instance, it calls @Remove for you.
>>>> >
>>>> >
>>>>
>>>> Thanks.
>>>> As far as I know, it is the client that invokes the remove method and
>>>> if
>>>> the
>>>> container passivates the SFSB the session bean will not reset its state
>>>>
>>>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>>>
>>>>
>>>>
>>>> -----
>>>> --
>>>> Regards
>>>>
>>>> Mohammad Norouzi
>>>>
>>>> Help each other to reach the future faster
>>>>
>>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>>
>>>> http://brainable.blogspot.com Brainable Blog
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>> thod-of-a-SFSB-tp26775547p26779956.html
>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>
>>
>> -----
>> --
>> Regards
>>
>> Mohammad Norouzi
>>
>> Help each other to reach the future faster
>>
>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>
>> http://brainable.blogspot.com Brainable Blog
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
>> thod-of-a-SFSB-tp26775547p26852910.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date:
>> 12/18/09
>> 19:38:00
>>
>>
>>
>
>
--
View this message in context: http://n4.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp979527p990784.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: transaction rolls back when returning from a remove method of a
SFSB
Posted by is_maximum <mn...@gmail.com>.
Thanks John, You said if this happens it seems that you do something that is
not allowed in the @Remove method but I add another method say remove() with
no body and no return value and just mark it as @Remove but still the same
problem exists.
I also monitored the pool and cache of app server to see what happens if I
don't call remove method and unfortunately each request I send that session
beans remains in cache and in method-ready state for a long time (the time
as set to be expired in app server configuration) and this is reallt bad!!
This application is a banking system and the performance is highly required!
John Ament wrote:
>
> I'm not disputing that part, remove is meant to say "Ok, I don't need this
> bean anymore." But it may be a case of something in the code that's in
> your
> remove is messing with the state of the bean. Since you can call it fine
> without the @Remove, the only likely scenario is that you're doing
> something
> that's not allowed in the @Remove method, but I honestly can't think of
> anything that falls into that scenario.
>
> -----Original Message-----
> From: is_maximum [mailto:mnrz57@gmail.com]
> Sent: Saturday, December 19, 2009 12:31 AM
> To: users@openejb.apache.org
> Subject: Re: transaction rolls back when returning from a remove method of
> a
> SFSB
>
>
> Hi
> As far as I understood from this document and EJB3 spec. if the client
> doesn't invoke the remove method, that instance wont be availablable for
> any
> other request and will be passivated until its timeout reaches and then
> the
> container will remove it and this has performance issues and we have to
> call
> remove method so release resources.
> I hope David can shed some light on this
>
>
> meetoblivion wrote:
>>
>> Sorry was thinking of Passivate/Activate
>>
>> Here's the more up to date docs:
>>
>> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>>
>> <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm
>> curious
>> to know what it is you're doing in postProcess, I'm still inclined to say
>> that it's behaving correctly but it depends on what you're doing in
>> there.
>>
>> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> meetoblivion wrote:
>>> >
>>> > What you're describing is exactly what's supposed to be happening.
>>> You're
>>> > not supposed to invoke the @Remove method from your own code. When
>>> the
>>> > bean
>>> > container passivates the instance, it calls @Remove for you.
>>> >
>>> >
>>>
>>> Thanks.
>>> As far as I know, it is the client that invokes the remove method and if
>>> the
>>> container passivates the SFSB the session bean will not reset its state
>>>
>>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>>
>>>
>>>
>>> -----
>>> --
>>> Regards
>>>
>>> Mohammad Norouzi
>>>
>>> Help each other to reach the future faster
>>>
>>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>>
>>> http://brainable.blogspot.com Brainable Blog
>>>
>>>
>>> --
>>> View this message in context:
>>>
> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
> thod-of-a-SFSB-tp26775547p26779956.html
>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>
> -----
> --
> Regards
>
> Mohammad Norouzi
>
> Help each other to reach the future faster
>
> http://pixelshot.wordpress.com Pixelshot Photoblog
>
> http://brainable.blogspot.com Brainable Blog
>
>
> --
> View this message in context:
> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
> thod-of-a-SFSB-tp26775547p26852910.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date:
> 12/18/09
> 19:38:00
>
>
>
-----
--
Regards
Mohammad
http://pixelshot.wordpress.com Pixelshot
--
View this message in context: http://n4.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp979527p990770.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: transaction rolls back when returning from a remove method of a SFSB
Posted by "John D. Ament" <my...@gmail.com>.
I'm not disputing that part, remove is meant to say "Ok, I don't need this
bean anymore." But it may be a case of something in the code that's in your
remove is messing with the state of the bean. Since you can call it fine
without the @Remove, the only likely scenario is that you're doing something
that's not allowed in the @Remove method, but I honestly can't think of
anything that falls into that scenario.
-----Original Message-----
From: is_maximum [mailto:mnrz57@gmail.com]
Sent: Saturday, December 19, 2009 12:31 AM
To: users@openejb.apache.org
Subject: Re: transaction rolls back when returning from a remove method of a
SFSB
Hi
As far as I understood from this document and EJB3 spec. if the client
doesn't invoke the remove method, that instance wont be availablable for any
other request and will be passivated until its timeout reaches and then the
container will remove it and this has performance issues and we have to call
remove method so release resources.
I hope David can shed some light on this
meetoblivion wrote:
>
> Sorry was thinking of Passivate/Activate
>
> Here's the more up to date docs:
>
> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>
> <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm
> curious
> to know what it is you're doing in postProcess, I'm still inclined to say
> that it's behaving correctly but it depends on what you're doing in there.
>
> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>
>>
>>
>>
>> meetoblivion wrote:
>> >
>> > What you're describing is exactly what's supposed to be happening.
>> You're
>> > not supposed to invoke the @Remove method from your own code. When the
>> > bean
>> > container passivates the instance, it calls @Remove for you.
>> >
>> >
>>
>> Thanks.
>> As far as I know, it is the client that invokes the remove method and if
>> the
>> container passivates the SFSB the session bean will not reset its state
>>
>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>
>>
>>
>> -----
>> --
>> Regards
>>
>> Mohammad Norouzi
>>
>> Help each other to reach the future faster
>>
>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>
>> http://brainable.blogspot.com Brainable Blog
>>
>>
>> --
>> View this message in context:
>>
http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
thod-of-a-SFSB-tp26775547p26779956.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>
>
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context:
http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-me
thod-of-a-SFSB-tp26775547p26852910.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.427 / Virus Database: 270.14.114/2574 - Release Date: 12/18/09
19:38:00
Re: transaction rolls back when returning from a remove method of a
SFSB
Posted by is_maximum <mn...@gmail.com>.
Hi
As far as I understood from this document and EJB3 spec. if the client
doesn't invoke the remove method, that instance wont be availablable for any
other request and will be passivated until its timeout reaches and then the
container will remove it and this has performance issues and we have to call
remove method so release resources.
I hope David can shed some light on this
meetoblivion wrote:
>
> Sorry was thinking of Passivate/Activate
>
> Here's the more up to date docs:
>
> http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
>
> <http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm
> curious
> to know what it is you're doing in postProcess, I'm still inclined to say
> that it's behaving correctly but it depends on what you're doing in there.
>
> On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>
>>
>>
>>
>> meetoblivion wrote:
>> >
>> > What you're describing is exactly what's supposed to be happening.
>> You're
>> > not supposed to invoke the @Remove method from your own code. When the
>> > bean
>> > container passivates the instance, it calls @Remove for you.
>> >
>> >
>>
>> Thanks.
>> As far as I know, it is the client that invokes the remove method and if
>> the
>> container passivates the SFSB the session bean will not reset its state
>>
>> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>>
>>
>>
>> -----
>> --
>> Regards
>>
>> Mohammad Norouzi
>>
>> Help each other to reach the future faster
>>
>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>
>> http://brainable.blogspot.com Brainable Blog
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp26775547p26779956.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>
>
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp26775547p26852910.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: transaction rolls back when returning from a remove method of a
SFSB
Posted by John Ament <my...@gmail.com>.
Sorry was thinking of Passivate/Activate
Here's the more up to date docs:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu
<http://java.sun.com/javaee/5/docs/tutorial/doc/bnbmt.html#bnbmu>I'm curious
to know what it is you're doing in postProcess, I'm still inclined to say
that it's behaving correctly but it depends on what you're doing in there.
On Mon, Dec 14, 2009 at 2:03 PM, is_maximum <mn...@gmail.com> wrote:
>
>
>
> meetoblivion wrote:
> >
> > What you're describing is exactly what's supposed to be happening.
> You're
> > not supposed to invoke the @Remove method from your own code. When the
> > bean
> > container passivates the instance, it calls @Remove for you.
> >
> >
>
> Thanks.
> As far as I know, it is the client that invokes the remove method and if
> the
> container passivates the SFSB the session bean will not reset its state
>
> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
>
>
>
> -----
> --
> Regards
>
> Mohammad Norouzi
>
> Help each other to reach the future faster
>
> http://pixelshot.wordpress.com Pixelshot Photoblog
>
> http://brainable.blogspot.com Brainable Blog
>
>
> --
> View this message in context:
> http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp26775547p26779956.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: transaction rolls back when returning from a remove method of a
SFSB
Posted by is_maximum <mn...@gmail.com>.
meetoblivion wrote:
>
> What you're describing is exactly what's supposed to be happening. You're
> not supposed to invoke the @Remove method from your own code. When the
> bean
> container passivates the instance, it calls @Remove for you.
>
>
Thanks.
As far as I know, it is the client that invokes the remove method and if the
container passivates the SFSB the session bean will not reset its state
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://old.nabble.com/transaction-rolls-back-when-returning-from-a-remove-method-of-a-SFSB-tp26775547p26779956.html
Sent from the OpenEJB User mailing list archive at Nabble.com.