a stateless session bean can not have its transaction opened across methods. the transactions has to be completed when the method ends. so we know the transactions boundry so that we can synchronize with the Database.

In entity beans(can have transactions span methods) we have ejbLoad() and ejbStore() to help us synchronize with the database

But in the case of a stateful session bean the tran can left open. so we dont exactly know when to synchronize with the db. so when u implement the SessionSynchronization interface it gives us three new methods that mark the beans transactional life.

Srividhya, thank you so much but I am still not clear. What is confusing me is the sentence "stateless session bean can not have its transaction opened across methods" - what does it exactly mean? Does it mean that when client accesses a stateless session bean that calls several of its own business methods, the transaction cannot span over all these method calls? I know that "transaction cannot span multiple invocation of the stateless bean" because it cannot preserve its state for later use. I think "Transaction Across Multiple Invocations" is different from "Transaction across multiple method invocations of the stateless bean", right?

My understanding is that a stateless bean can have more than one business methods - am I right? If the answer is NO, then I am not sure why it may not? I yes, how does this fit into above quoted sentence?

Since I am new to EJBs and I have your attention, here is another naive question:

Can Entity Beans only run in a CMT and never in a BMT? - Yes, entity beans only run in CMT.

Coming to the question on transactions - stateless session beans cannot start a transaction in one method and close it in a different method => cannot leave a transaction open across business method calls.

However, it is possible to use a BMT for a stateless session bean which during the course of transaction calls several methods and does a commit or rollback in the method where the transaction was started. For CMT, the scope of a transaction is that method -> method ends => transaction ends.

Balaji Anand

Ranch Hand

Posts: 146

posted 12 years ago

hi I am also preparing for my SCBCD. This is what my understanding is.

I am sorry what abt the confusion... Stateless session beans arent allowed to maintain a transaction once a method has ended. Only Stateful session beans with CMT implements SessionSynchronization. A Statelss session bean can have more than one business methods.

Assume Client C.A CMT Stateless Session bean business methods A,B,C. A inturn calls B. when the client calls A... it starts a transaction TxA and the transaction ends when it exits A. B can be either TxA or a new Tran or no tran depending on the tran attribute of B. When the Client calls C after this it will be in a new transaction of its own.

So here we know the tran starts and ends in the same method. so we can sync with the db easily.

Since we have a stateless session bean (which does not passivate and I believe that container will not serve two clients with same stateless session bean concurrently), why a transaction (let us say we have BMT) cannot span multiple methods? We should be able to start TX in one method and should be able to perform various things by calling whatever other methods and then complete the transaction- right?

One more question:

I recently read this in a document and I am not sure what it exactly means. Here is the sentence: "Session bean's conversational state is NOT transactional". There is no mention of whether this statement is about stateless or stateful SB.

Thank you again! Saeed

Balaji Anand

Ranch Hand

Posts: 146

posted 12 years ago

the answer to your first question... The stateless beans dont passivate and it serves one client only when it is in a business method. but the problem is... after the method completes it goes to its pool. so when the client calls the next business method, it may not get the same bean again. I guess if we close it in a different method, there are chances that method of that bean never gets called.

7.4.2 and 7.5.3 from the spec talks about the conversational state being non transactional. I think it mostly refers to the Stateful session bean. In general it means... say if a method rollbacks the conversational state is not restored to the initial state. so we have to manually reset the transaction. In case of stateless session bean we know when the transaction ends (in the same method) so we can reset it in case of a rollback. but in stateful session(where the transaction can be left open), we have to use the afterCompletion to sync with the db incase of rollback. [ March 15, 2006: Message edited by: Srividhya Anand ]

As per the specification 1. Stateless session bean should not implement SessionSynchronization interface 2. Statefull session bean with BMT should not implement SessionSynchronization interface. 3. Only Statefull session bean with CMT can implement SessionSynchronization interface.

I know that in case of CMT when the transactional method starts, a transaction is started and when the method ends, the transaction ends. Example: Client calls a method on CMT statefull session bean with transaction attribute of required. A new transaction is created before executing the method and ends as the methods completes.

My understanding is the above statemenet is valid for both statefull and stateless CMT session beans.

If I am correct then why I am not allowed to implement session synchronization interface for stateless session bean with CMT ?