-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Rollback transaction, rollback bean
PostPosted: Mon Nov 24, 2003 7:24 pm 
Beginner
Beginner

Joined: Thu Nov 20, 2003 1:30 pm
Posts: 27
In a web MVC architecture you have a "Form Bean" which is the transport from the UI to the Model. These beans usually have a lifespan of the request scope.

My problem is with a (Swing) desktop, I create a UI to edit a hibernate model bean. The user edits the fields, simple validation is done when they click save, then if this validation is correct, all the UI data is set onto to model bean and that bean is passed to a transaction.

Sometimes more validation has to be done inside the transaction.

Let me give an example of updating a Member.

1. Member object is loaded onto Swing UI.
2. JTextFields, etc are populated, user edits information.
3. Save is pressed.
4. Simple validation is done
5. Test if the user changed their e-mail address.
(This test is done by comparing the model bean's email address and the e-mail address on the UI)
6. Set UI data to model bean.
7. Send model bean to transaction.
8. Transaction tests if the the zip code entered is valid (zip code exsits in another table)
9. If not, throw error and return to UI.
10. Otherwise if transaction is sucessful, ask the user if they want to send an e-mail to the member notifying them their e-mail address was updated.

As you might have have found, if step 9 happens, the model bean is out of sync with the database. The model bean has the information from the UI on it and not that database. The next time the user presses save, the code will not detect that the e-mail address has been changed.
2 solutions I came up with are:
1. Clone the model bean before step 6 and set the UI data on the clone, then if step 8 completes successfully set the clones over the orginal.
2. In step 8, if it ever rollsback, refresh the beans from the database automatically.

With struts you have "Form Beans", eliminating this transport issue. I would rather not have another model layer between the UI and the transaction as this "form" layer would be almost identical to the database model layer.

Does anyone have an application architecture similiar to this?
What did you do to avoid this problem?

Thanks


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.