Your class should have a instance variable where the timestamp will be held. You do not have to put a timestamp into the database. The timestamp variable in the object is used by Castor to see if the object has been modified.
So, you will open a transaction, load the object and close the transaction. Then the user (probably after a 20-minute break) will changed the object. Afterwards you will open a transaction, make it persistent and close the transaction.
AFAIR the only one thing you have to change in your mapping is you have to set up a cache.
But, I have encountered several problems by using long transactions. And I have changed Castor to get run. But now I have other problems, like I am not able to use collections directly.
But perhaps you should look into the archive of the mailing lists. In the past there were several people which have problems with long transactions.
Kind regards Rainer
Keld Helbig Hansen schrieb:
On Castor's web site you can read about long transactions:
http://castor.exolab.org/long-transact.html
It says
"Since the time interval between the first and the second transaction is relatively big, it is desirable to perform dirty checking, i.e. to check that the object has not been modified in the database during the long transaction. For that the object must hold a timestamp: it is set by Castor during the first Castor transaction and is checked during the second one. In order to enable the dirty checking for long transactions, the object should implement the interface org.exolab.castor.jdo.TimeStampable having two methods:
long jdoGetTimeStamp()and void jdoSetTimeStamp(long timeStamp)"
I don't quite get this: It doesn't say that you should put the timestamp on the database, so how does it work? If someone else updates the db while I'm in a long transaction, how should I be able to recognize this if I only check a timestamp set in my local instance of the class???
The well-known timestamp check as I know it works if you put a timestamp on the database, and it works like this:
1. read a record from the db, keep the data including the "last modified" timestamp 2. think....... 3. now we're ready to update the db: 4. read the record once more. 5. check if the current timestamp is the same as the one we read long a go. 6. if identical, update the record 7. if not identical tell the user that he has to redo his update (since someone else updated the record while he was thinking......)
I'd also appreciate if anyone could tell me if I need to add anything to the mapping file to make long transactions work.
Thanks a lot for any help......
/Keld
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-- Institut fuer Seeverkehrswirtschaft und Logistik http://www.isl.org/ Dipl.-Inf. Rainer Mueller mailto:[EMAIL PROTECTED] Universitaetsallee GW1 Block A tel:+49 421 22096-65 D-28359 Bremen fax:+49 421 22096-55
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
