Hi Alex: I'm just curious ... why don't you want to keep client-specific state in local variables in the stateless session bean method, and non-client-specific state in the instance variables of the stateless session bean? (As Anish mentioned, these variables could of course hold instances of plain-old java classes, and the stateless session bean could delegate to these instances.) What is the stateful session bean giving you that local and instance variables don't?
I agree with your statement: "It seems that statefull session beans then, are only good when they are used by the EDGE clients (the real client at the end of the chain), and cannot reliably be used when the client is yet another EJB." Laurel -----Original Message----- From: Alex Paransky [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 1:06 PM To: [EMAIL PROTECTED] Subject: Re: Question regarding removing of statefull session beans during a transaction... I agree, statefull session beans are for keeping client state across method invocations. In this case, however, my client is another EJB bean (stateless session bean). It keeps the statefull session bean around, to keep track of it's own internal state (it's own client state). At a certain time, it decides that it needs to get rid of the inner bean and needs to remove it. Because the transaction attribute is TX_SUPPORTS, I cannot reliably remove the inner bean. So I am at a loss of what to do. It seems that statefull session beans then, are only good when they are used by the EDGE clients (the real client at the end of the chain), and cannot reliably be used when the client is yet another EJB. -AP_ -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters Sent: Thursday, October 04, 2001 10:44 AM To: [EMAIL PROTECTED] Subject: Re: Question regarding removing of statefull session beans during a transaction... Why are you creating a statefull session bean and then destroying it within the same transaction? At least to me that seems to raise the question of why are you using a statefull session bean? It would seem creating a regular Java object inside your method and store the state there would make more sense (and eliminate the problem as well). Stateful session beans are really for keeping client state across method invocations, not inside of them. Cheers -----Original Message----- From: Alex Paransky To: [EMAIL PROTECTED] Sent: 10/4/01 1:12 PM Subject: Question regarding removing of statefull session beans during a transaction... I have posted this question before, but really did not get any replies, so I decided to post it again. During a transaction, I create a statefull session bean, and use it. At the end of the method, I attempt to call remove on the statefull session bean, however, I get an exception stating that statefull session beans cannot be removed during a transaction. This IS what is in the spec. My question then, is how do I "cleanup" after creating a statefull session bean? I am using container managed transactions, so by the time the transaction ends, I don't have access to the local variable which was holding the statefull session bean. Could someone shed some light on this issue, please... Thanks. -AP_ ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
