G'day
I do use it, but I will let you decide if the UserTransaction stuff would be better.
I use it probably out of a bit of laziness, I will try and explain: I have an Entity
(lets call it mum) which I also use as a backing bean for a form. it has a collection of
objects (Entity as well) on it (lets call each one a kid).
Now On the form I have a button which calls an action to add another new (blank) Kid to
the list so that the details of a new Kid can be filled in, I also have a delete button to
remove a Kid. Now in the basic case if I click on the add or delete the associated action
(in a SFSB) causes the injected Backing bean to get saved to the DB (as it is an Entity).
But I only want the data saved IF they press the done button, this is so when they press
Cancel nothing would have changed, even if they added or deleted Kids before hitting
Cancel..
So the add and delete methods both use @Rollback. This allows the new entries to be added
to the list and the data in the backing bean to be updated but it will not be flushed to
the DB unless the Done action is called which Doesn't have a @Rollback on it.
As it is a very simple data entry problem I went with the Entity being re-used as a
backing bean (I mentioned me being lazy). An easy workaround if Rollback wasn't there
would be to use seperate backing beans ands entities, and use a bit of code to copy the
backing dean data to the entry on the done action (I use this in all my more complicated
forms). I also assume there is a way to control the transactions to do what I do without
@Rollback, but using it means I only need the one annotation to get the desired result, so
as you can imaging the code to do the above is very simple and sparse.
Cheers
Paul.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980913#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...