Undo/Redo of RDBMS committed transactions
Hi All,
I have the following scenario and wondering if Command design pattern would be a solution and looking for your valuable advice.
The application I am working on is a three tier application with front end Swing, middile tier application server and back end RDBMS.
As the user makes changes in the front end, those changes will be saved to the RDBMS as transactions. We would like to provide the user with an option for undoing the recent operation, which should undo the recently committed transaction of this particular user on the RDBMS. We also want to provide the user with Multi-Level undo and redo operations.
Just wondering how to implement this. I am thinking about Command design pattern, but I have no idea of it used in this kind of scenario. I appreciate if you can provide your ideas and pointers on this subject.
Many thanks,
Srinivas.
[898 byte] By [
sri_bitlaa] at [2007-11-26 12:49:46]
# 2
How does your Command pattern know how to write compensating transactions?
If you update, you have to maintain the state of the row before the update.
If you delete, you have to maintain the state of the row before the delete.
If you insert, you have to create a compensating delete transaction.
Sounds like one hell of a lot of work. How many levels do you expect to maintain? How many simultaneous users? What if one user's transaction trashes that of another? How will you maintain ACID for all the compensating operations?
Is this a firm business requirement, or a "nice to have"?
I'd prefer that you leave transactions to the database, but that's just my opinion.
%
# 3
Hi duffymo,
Thank you very much for your opinion. Its really helpful.
Following are my comments.
> How does your Command pattern know how to write
> compensating transactions?
>
Compensating transactions can be written as insert for delete,
delete for insert and update for update and we can make
the commands aware of their respective compensating
transactions for undo operations.
> If you update, you have to maintain the state of the
> row before the update.
>
> If you delete, you have to maintain the state of the
> row before the delete.
>
> If you insert, you have to create a compensating
> delete transaction.
>
Yes, I have to. I think that is where Memento design pattern
plays a role. Memento can be used in conjenction with
Command design pattern to store the state of an object.
Additionally, I can use Composite with Command to group
Commands together and execute them as Composite command.
> Sounds like one hell of a lot of work. How many
> levels do you expect to maintain? How many
> simultaneous users? What if one user's transaction
> trashes that of another? How will you maintain ACID
> for all the compensating operations?
>
There are not a lot of users who use this application. May be a
couple of simultaneous users and I can configure how many
levels I have to maintain, may be 10 or 20 levels. The users work
on different datasets so one users transaction will not trash that
of another. Regarding maintaining ACID, commands and
undo commands are executed as single and seperate
database transactions. An undo operation is an entirely
new transaction to the database. So I think that way I can
meet ACID requirements.
> Is this a firm business requirement, or a "nice to
> have"?
>
Well this is not a firm business requirement. I am only considering
this as a nice to have feature knowing that the users tend to
make many accidental mistakes in their work.
I will definitely give it a lot of thinking before doing, but now exploring
the possibilities and for some pointers to implementations
of command design patterns.
Thank you very much for your time duffymo.
Thanks,
Srinivas.
