Hi Rainer, Thanx for your comments. But I still don't understand this. What exactly does Castor do when it checks if the object has been modified? What does it compare the timestamp value in our instance with???? There's no timestamp in the db. What if the record is updated by another application??? I'd be very gratefull for information on how this might work /Keld ----- Original Message ----- From: "Rainer M�ller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 28, 2003 5:40 PM Subject: Re: [castor-dev] Long transactions - how does it work???
> Hi Keld! > > 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 > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
