how to avoid transaction aborting 2006-01-19 - By Mike New
Back
> Hi, Dear guys
> I really hope you can help me to solve this problem.
> for example:
> i open two transactions which both get access to same record in
> database. so two objects are loaded for this record. and in these two
> transactions, both of these object(mapped to same record) are modified.
> upon committing, one these two transactions will be aborted (dirty
> modification). and user lost all the data. I think it is not acceptable
> for user. and these problems happen quite often since the many
> transactions in our system are long transactions which last over ten
> minutes or longer.
>
> Could anyone can give me some hint? i search internet and did not get
> some userful info related to that?
> I don't know if it is practicle to implemented dirty checking before
> committing anything to database in transaction?
A database transaction should take milliseconds, not minutes. If you need
long running transactions you will have to create some kind of temporary
object which is then "committed" (i.e. overwrites the current object).
As for two users modifying the same data, I think you have to decide
exactly what behaviour you want and program it yourself. Long-running
database transactions are not the answer, because that's not what database
or J2EE transactions are meant for. Also, I don't think you can have two
transactions open on the same data. I can't imagine what that means.
So you could do something like this:
User A makes a change to some data:
The data field is copied, a "LongTransaction" object is created, a
normal transaction is started, the change is made, and the
transaction is committed. The temporary data is stored but the
original data is intact.
User B makes a change to the same data:
The system gets a reference to the LongTransaction, noting it is in
progress. This gets the temporary copy of the data, makes its
change and commits it.
User A makes another change:
Same thing again. All these changes are made on the copy until
there is an explicit "commit" called on the LongTransaction.
Finally, case 1 or case 2:
Case 1: User X rolls back the transaction.
The LongTransaction is told to roll back. It removes the temporary
object from memory and from the database. The original object is
still intact.
Case 2: User X commits the LongTransaction:
The temporary data copy replaces the original copy. The
LongTransaction is finished/destroyed/cleaned up.
The above is simplistic, but I hope you get the idea.
Mike
-- ---- ---- ------ _/ /// // -- ---- ---- ---- --
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
|
|
