how to avoid transaction aborting 2006-02-08 - By bin cai
Back
Thank you very much, Mike. I will do more research on this issue.
bin
Mike New <mike@(protected)> wrote:
> 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".
-- ---- ---- ---- ---- ---- -----
Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.
===========================================================================
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".
<div>Thank you very much, Mike. I will do more research on this issue. </div>
<div>bin<BR><BR><B><I>Mike New <mike@(protected)></I></B> wrote:</div>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT
: #1010ff 2px solid">> Hi, Dear guys<BR>> I really hope you can help me to
solve this problem.<BR>> for example:<BR>> i open two transactions which
both get access to same record in<BR>> database. so two objects are loaded
for this record. and in these two<BR>> transactions, both of these object
(mapped to same record) are modified.<BR>> upon committing, one these two
transactions will be aborted (dirty<BR>> modification). and user lost all
the data. I think it is not acceptable<BR>> for user. and these problems
happen quite often since the many<BR>> transactions in our system are long
transactions which last over ten<BR>> minutes or longer.<BR>><BR>>
Could anyone can give me some hint? i search internet an
d did
not get<BR>> some userful info related to that?<BR>> I don't know if it
is practicle to implemented dirty checking before<BR>> committing anything
to database in transaction?<BR><BR>A database transaction should take
milliseconds, not minutes. If you need<BR>long running transactions you will
have to create some kind of temporary<BR>object which is then "committed" (i.e.
overwrites the current object).<BR><BR>As for two users modifying the same data
, I think you have to decide<BR>exactly what behaviour you want and program it
yourself. Long-running<BR>database transactions are not the answer, because
that's not what database<BR>or J2EE transactions are meant for. Also, I don't
think you can have two<BR>transactions open on the same data. I can't imagine
what that means.<BR><BR><BR>So you could do something like this:<BR><BR>User A
makes a change to some data:<BR>The data field is copied, a "LongTransaction"
object is created, a<BR>normal transaction is started, the
change
is made, and the<BR>transaction is committed. The temporary data is stored but
the<BR>original data is intact.<BR><BR>User B makes a change to the same data:
<BR>The system gets a reference to the LongTransaction, noting it is in<BR
>progress. This gets the temporary copy of the data, makes its<BR>change and
commits it.<BR><BR>User A makes another change:<BR>Same thing again. All these
changes are made on the copy until<BR>there is an explicit "commit" called on
the LongTransaction.<BR><BR>Finally, case 1 or case 2:<BR><BR>Case 1: User X
rolls back the transaction.<BR>The LongTransaction is told to roll back. It
removes the temporary<BR>object from memory and from the database. The original
object is<BR>still intact.<BR><BR>Case 2: User X commits the LongTransaction:
<BR>The temporary data copy replaces the original copy. The<BR>LongTransaction
is finished/destroyed/cleaned up.<BR><BR><BR>The above is simplistic, but I
hope you get the idea.<BR><BR>Mike<BR>-- ---- ---- ------ _
/ /// //
-- ---- ---- ---- --<BR><BR>==================================================
=========================<BR>To unsubscribe, send email to listserv@(protected)
and include in the body<BR>of the message "signoff J2EE-INTEREST". For general
help, send email to<BR>listserv@(protected) and include in the body of the
message "help".<BR></BLOCKQUOTE><BR><p>
<hr size=1>Brings words and photos together (easily) with<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/PMDEF3/*http://photomail.mail
.yahoo.com">PhotoMail </a> - it's free and works with Yahoo! Mail.
===========================================================================
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".
<p>
|
|
