There are a number of reasons for this. The main one being that our operations are abstracted.
For example, when you press the gas pedal on your car, can you really keep the entire state of the car in local variables? The car, functions like a statefull session bean. You apply the gas pedal (execute a method), and the state changes. How it changes, or what it does, is not of your concern as long as you are driving faster. When you press on the break (execute another method), the car slows down. Is able to slow down, because it has "remembered" the state from the previous operation (applying the gas pedal). Your transaction, can be seen as driving to work. You get into your car (transaction begin), you start the car (create statefull session bean), drive the car by applying options such as steer, accelerate or break (execute methods), these operations cause a change in the car's performance (change in state) which are remembered between the operations (statefull session bean). Now you stop and turn off the car (remove statefull session bean). You exit the car because you have reached your destination (end of transaction). In other cases, you may need to create a distributed Iterator. Thus there must be some memory between the two getNextNObjects(...) calls. We have created an Iterator over the results of an extensive search. While we don't want to search the entire collection at once, we proceed with incremental search as the client requests more records. It could be the case, that the client satisfied with the number of records received, does not exhaust the iterator to the very end. Thus it would be foolish to get ALL the records that satisfy a particular search criteria, because all the records are not needed. I guess all this is really a moot point, since the fact remains that you cannot effectively use a Statefull Session Bean on the EJB server and continue using Container Managed Transactions. However, when you start using bean managed transactions, that greatly effects how and where the bean can be used. -AP_ -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Laurel Neustadter Sent: Friday, October 05, 2001 6:35 AM To: [EMAIL PROTECTED] Subject: Re: Question regarding removing of statefull session beans during a transaction... 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". =========================================================================== 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".
