BMT from POJO ?

[Saha Kumar]

Hello All,

Can a UserTransaction be started in a POJO and propagated to another POJO? I am finding that most of my transaction handling is carried out within one or more POJOs (instead of within SLSBs).

Thanks in advance.

-Saha

[Saha Kumar]

Hello All,

Could someone tell me if the following is a good practice or is valid use of BMT.

- A SLSB is executing code without CMT or BMT

- The SLSB instantiates and calls a method in a POJO with its javax.ejb.SessionContext as a parameter.

- The POJO uses context.getUserTransaction() to start a transaction, then performs a database update.

- The POJO then instantiates and calls a method in a different POJO which then executes some code in the same transaction.

- The second POJO returns to the first where the transaction is either rolled back or committed

Thank you in advance.

-Saha

[Saha Kumar]

Hello All,

I have answered my question.

I'll create a class which contains UserTransaction (obtained from SLSB facade), and use it in the pojos. This should work since SLSB are single-threaded. Note that this functionality is not available for servlets. In the servlet case, a transaction cannot span multiple servlets. But pojos instantiated from a SLSB can use the same transaction.

Sorry for the question.

-Saha

[Saha Kumar]

Note that the UserTransaction object is obtained from the SLSB's ejbContext... not using JNDI. Also, the SLSB has not been configured with CMT.

Correct me if any statements on this topic are incorrect.

Many thanks.

-Saha

[Rama Bhargav]

- A SLSB is executing code without CMT or BMT

- The SLSB instantiates and calls a method in a POJO with its javax.ejb.SessionContext as a parameter.

- The POJO uses context.getUserTransaction() to start a transaction, then performs a database update.

- The POJO then instantiates and calls a method in a different POJO which then executes some code in the same transaction.

- The second POJO returns to the first where the transaction is either rolled back or committed

I am not sure why you did not want to use CMT. You could use CMT by having a method in SLSB start the Transaction. The flow goes like this.

SLSB method() starts the transaction and calls --> Pojo1.methodX() --> pojo2.methodY(). The transaction context will be propogated thru the thread of execution all the way. This way, you do not have to demarcate the transaction boundaries programmatically with txn.begin(), commit() or rollback().

[Saha Kumar]

Hello Rama,

Thanks for posting. At first I wanted to use CMT and have it applied to methods in each facade. The problem occurs when one use case calls another without returning to the browser (or Swing application) first. I wanted to commit an update in one use case, and then continue on and commit a second update. It just seems more flexible by using BMT.

-Saha

[Saha Kumar]

Rama,

I also wanted (if possible) to use only one SLSB per round trip from client to server and back to client. I did not want one use case facade calling another use case facade. I am hoping this design choice provides better response time and is worth the extra effort. What do you think?

-Saha

[Rama Bhargav]

I wanted to commit an update in one use case, and then continue on and commit a second update.

If I understand you correctly, you want to have two different transactions in one server trip. You can accomplish this using CMT also as expalined below.

facade1.save(). TX Attrib: TX_REQUIRES_NEW / TX_REQUIRED
facade2.update(). TX_REQUIRES_NEW / TX_REQUIRED

facade1.saveAndUpdate(). TX_SUPPORTS. This method calls facade1.save() and facade2.update().

If your client calls saveAndUpdate() without any client initiated TX context, then save() method will be executed in its TXN, then once it is finished, facade2.update() will be run in its own txn.

I also wanted (if possible) to use only one SLSB per round trip from client to server and back to client. I did not want one use case facade calling another use case facade. I am hoping this design choice provides better response time and is worth the extra effort. What do you think?

I agree that there should be only one network trip to server for one client request. However, about one facade calling another another facade, it depends on how you design and delegate responsibilities between Facades and POJOs. I will have my facades with useCase level methods such as saveItinerary, priceItinerary etc.. which inturn delegate to Application service classes. My facades would handle the Transactions using CMT as explained above.

[Saha Kumar]

Hello Rama, hello All,

Thank you for the well-thoughout posting.

Looking at chapter 7 of 'Core J2EE Patterns' second edition, I see that a service/session facade can call more than one applicationService.

To incorporate your suggestion with what I read, the following may satisfy it.

facade.task1 {
facade.task1Part1();
facade.task1Part2();
}

facade.task1Part1(){
appServicePart1();
}

facade.task1Part2(){
appServicePart2();
}

where method facade.task1 has no transaction assigned to it,
facade.task1Part1 has REQUIRES_NEW, and facade.task1Part2 has
REQUIRES_NEW.

In addition, is the following acceptable if CMT is used on methd pay shown below?

pay {
try{
nonTransactionalTask();
transactionalTask();
}catch (SystemException se){
undoTransactionalTask();
throw se;
}
}

Please let me know if the information in this post is valid and/or good design.

Thanks in advance.

-Saha
[ April 27, 2006: Message edited by: Saha Kumar ]

[Rama Bhargav]

Saha,

I agree with you. But for the pay method, I am not sure what you intend to do in the undoTransactionalTask(). Any transaction aware operations such as database manipulations you performed within the TX boudaries will not be committed if there is an unhandled ejbException.

In case of SFSBs with CMTs, if you want to restore the SFSB state to the previous state in case of a transaction rollback, your SFSB has to implement SessionSynchronization interface.

pay {
try{
nonTransactionalTask();
transactionalTask();
}catch (SystemException se){
undoTransactionalTask();
throw se;
}
}

[Saha Kumar]

Hello Rama,

The nontransactionalTask is, for example, authorize credit card payment. I am currently changing this.

I do have a related question:

I am using SFSB as a user session (temporarily store business objects), so I am not using CMT there. I am still working on how to use CMT, with the combination of BusinessDelegates, SessionFacades (SLSB), AppServiceFacades, and appServices. In addition, I already have a SFSB.

As I see (from 'Core J2EE Patterns'), the design requirements are:

1) tight coupling between BusinessDelegates and SessionFacades, with SessionFacades just delegating to serviceApps or serviceFacadeApps.

2) a service facade should not call another service facade

3) it is okay for an appService to call one or more other appServices.

4) a service facade can call one of more appServices.

If I want to reduce:

BD -> SessionFacade (SLSB) -> serviceAppFacade (SLSB) -> serviceApp

to:

BD -> SessionFacade (SLSB) -> serviceApp

then I see no choice but to use BMT; or

would you say that:

BD -> SessionFacade (SLSB) -> serviceAppFacade (SLSB) -> serviceApp

is a good, acceptable design? I was trying to reduce the number of SessionBeans.

Thank you in advance.

-Saha

[ April 28, 2006: Message edited by: Saha Kumar ]
[ April 28, 2006: Message edited by: Saha Kumar ]

[s khosa]

Problem with this approach is:

BD -> SessionFacade (SLSB) -> serviceAppFacade (SLSB) -> serviceApp

- What would happen to exception handling particulalry if you are using/executing multiple/nested transaction. Who tells what and to whom and how !!!... in case exceptions occur.

Again no design is perfect....as long as you can plan out/justify things around it you should be fine.

Thanks

[Saha Kumar]

Hello s kosa, hello all,

Thanks for the reply! I think I will stay with the TransactionMgr class that I created to gain more flexability. Glad to have help making the choice.

-Saha