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:[email protected]]
Sent: Saturday, December 19, 2009 12:31 AM
To: [email protected]
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 <[email protected]>
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.
