loseDatabase(db);
}
}
Just update in transaction. Sure, db.update not used...
I need a some rest, I guess :))
Sorry, again
-Original Message-
From: Bruce Snyder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 8:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Long Transactions s
Ok, I try perform some tests to invoke this
-Original Message-
From: Bruce Snyder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 8:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Long Transactions suggestion
This one time, at band camp, Alexey A. Efimov said:
AAE>
This one time, at band camp, Alexey A. Efimov said:
AAE>The long transactions as it described by link you posted is not work
AAE>correctly, I mean that method update can throw any time
AAE>LockNotGrandedException... Did you try to use this?
AAE>Maybe I miss some bugfixes, but I remember that it d
This one time, at band camp, Alexey A. Efimov said:
AAE>I know about two problems with long transactional support:
AAE>The first problem - is closing QueryResults after db.commit(). But, I
AAE>think, is good, because if you use lazy loading and browse QueryResults
AAE>in "offline", that should be
Hi all,
I have a suggestion how to improve long transaction support, although I
don't know if it's a good one...
My idea is no to close a result set if the object type that was queried
implements the Timestampable interface. This would make life much easier
wenn working with long transactions.
