Design Question - long transaction
1 posts in topic
Flat View  Flat View
Older Post First |   Reply to Topic
TOPIC ACTIONS:
 

Posted By:   avihaimar_marchiano
Posted On:   Friday, May 4, 2007 11:56 AM

Hey, My client is a swt client that runs on machine A and the server is a J2ee server that runs on machine B. We use facade design pattern and the API are exposed to the client as a stateless session bean. The user does some configuration changes. for change (like add new components ... ) we need to go to the server in order to create or edit the component (the client doesn't have the knowledge how to do this) in the end of the configuration process the user may press on the persist button and all the changes need to be persist. The concept that i need to implement is similar to the concept of editing word document all the changes are saved in temporal document until the user click on save or close the    More>>

Hey,

My client is a swt client that runs on machine A and the server is a J2ee server that runs on machine B.
We use facade design pattern and the API are exposed to the client as a stateless session bean.

The user does some configuration changes.
for change (like add new components ... ) we need to go to the server in order to create or edit the component (the client doesn't have the knowledge how to do this)
in the end of the configuration process the user may press on the persist button and all the changes need to be persist.

The concept that i need to implement is similar to the concept of editing word document all the changes are saved in temporal document until the user click on save or close the document.

As I see it I need long transaction here, but stateless doesn't support in long transaction and there are a lot of problems (time out and etc) in a long transaction.
I have to save those "temporal configurations" to the DB, because I need to get id for these configurations and other operations.

Does any one have an idea how to implement it?

It is important to remember that if the user edit an existing component other user don't see those changes unless he press on the save button. This scenario can lead to conflict.

Thank you.
Any idea will be welcomed.

   <<Less
Report | Quote This | Send private message | Reply | Print

Re: Design Question - long transaction

Posted By:   Robert_Lybarger  
Posted On:   Friday, May 4, 2007 10:33 PM

No thoughts on implementation details (your problem is beyond the toy projects I've backed with a DB so far) but could you create or utilize a "temporary" table in the database, and to prevent user collision, have some indicator in your regular table (foreign key pointing to row in the temp table) to indicate an edit is still pending. Use "commits" and the info from the temp table is used to update the real table, the temp table is cleared, and the foreign key is cleared to indicate the data is now saved. Now the question becomes what to do if the user breaks connection without explicitly rolling back their pending changes (connection loss, app crashes, etc.) ... no immediate answer to that. However, thinking another way, this is the sort of problem that source code revision systems solve: lock one developer out of a file while another developer is working on it, but provide a way to steal back the "lock", so to speak. You might see what conceptual patterns and solutions they have already thought of and map them to your database/app.
Report | Quote This | Send private message | Reply | Print
About | Sitemap | Contact