Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

CMP transaction  RSS feed

 
anupa oru
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks,
I need some help with design of my CMP(where bean is local to calling client).
Design:
1.will have CMP with set&get methods for id,name,city,zipcode where id is the primary key.
2.will call CMP from POJO,which will look up bean and set those fields.I have to satisfy these conditions a.according some business rules I may need to insert a new record or need to update all fields except id if id already exists.if id is there,all other fields should be updated in transaction as well as while insertion all fields must be inserted in a transaction.
according to my design I am thinking to have the following trasaction attributes
setid----requiresnew
setname----required
setcity----required
setzipcode----required
This POJO class will throw whatever exceptions that are occured in EJB to presentation layer.
My question is since container maintains transactions for my CMP,suppose when setting city if remote or SQLException occurs is container going to rollback name value also.I heard that container will only rollback if it get EJBexception from method,is that true .in my case since all EJBExceptions will be converted to application specific exceptions,is my design going to satify my business requirements.

Please reply me.If question is n't clarified to you,please don't hesitate to ask.
Thanks alot folks,
waiting for your reply.
Anu
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could write a finder and decide whether to insert or update depending on what it returns. As your POJO is presumably not running in a transaction, you only need Required as the trans atribute for your bean methods.

Alternatively, you can just insert without first doing a finder, in which case the client may get a DuplicateKeyException if the entity object cannot be created because an entity object with the same key already exists.

If SQLException is thrown, you should throw EJBException which wraps this exception, thus causing the transaction to be rolled back. This is what you want, so why are you going to convert EJBException to an application exception?
 
anupa oru
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Roger Chung Wee,
Thanks alot for your reply.Whenever SQL Exception/EJB Exception occurs I need to report that to presentation layer as "UNEXPECTED_MIDDLEWARE_EXCEPTION",that's why I need to convert that to application specific expection.
Lately I was thinking of having business method in Bean class,which will call set methods of Bean class and will have Required Transaction attribute.Incase if exception occurs in any of set methods any way that method won't be commited so there won't be any dataintegrity problem(such as updating name but not city).
But I am kind of confused about one thing,I am assuming that container won't commit the transaction unless it succeeds is in it right.If so if SQLException happens,container not yet commited the trasaction so aren't we safe.
if we have methods such as setCity,setZipCode,setName with "Required",if SQLException occurs in setZipCode so ZipCode won't be set(trnsaction is commited after successful completion of method) and what about name is it will be updated or not.Are you saying if SQLException happens,then container has to get EJBException then only it will rollback city field?.


Please reply me,I am in need of your valuable opinion so I can make wheel to move forward.
Thanks alot,
Anu
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks alot for your reply.Whenever SQL Exception/EJB Exception occurs I need to report that to presentation layer as "UNEXPECTED_MIDDLEWARE_EXCEPTION", that's why I need to convert that to application specific expection.

If the client receives EJBException, then it knows that the bean or the container must have thrown it, and that the transaction will rollback.

if we have methods such as setCity,setZipCode,setName with "Required",if SQLException occurs in setZipCode so ZipCode won't be set(trnsaction is commited after successful completion of method) and what about name is it will be updated or not.

SQLException is a checked exception, so the container will commit the transaction when it is thrown. But you will hardly ever allow such a low-level exception to be thrown to a client, so you must either throw EJBException or invoke EJBContext.setRollbackOnly and then throw an application exception. Either option will ensure transaction rollback.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!