I'm solely using long transactions and no cache across multiple servers (apparently with the wrong CVS version, sorry Thomas :) ). I store the timestamp in the db, and this seems to be the safest for my uses. The only real problem is that in order to do it, we need to hit the db more (extra step to reload new Timestamp into object). However, we don't mind the performance hit because we need the data integrity.
Trevor D. Cook
-----Original Message-----
From: Keith Chew
To: [EMAIL PROTECTED]
Sent: 31/10/01 8:12 PM
Subject: Re: [castor-dev] suggestion
I have read articles that timestamp check is not a full proof check. The
safest is to check all the fields.
But I do agree with you, moving the timestamp to the DB would be a good
move. At least it's a method that can be used without cache.
Good suggestion Matthew
Keith C
-----Original Message-----
From: Matthew Baird [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 1 November 2001 1:58 p.m.
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] suggestion
although I agree this is A way of achieving this, another, possibly
better,
way would be to patch castor to allow the timestamp to be moved into the
db,
and use that on update, thus mitigating the need to have cache on for
long
transactions.
-----Original Message-----
From: Keith Chew [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 31, 2001 4:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] suggestion
Maybe I wasn't clear in my explanation. I suggested turning cache off
and
storing a deep copy of the object in the object. In other words, the
object
is now holding the old value, which will eliminate the need for cache on
an
update. It comes with the tradeoff that the object is now double the
size
(well, of course you can optimise this).
This will work nicely in a clustered app server environment, as Castor
does
not support distributed cache (yet).
Keith C
-----Original Message-----
From: Thomas Yip [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 1 November 2001 12:04 p.m.
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] suggestion
See inline.
-----Original Message-----
>From: Keith Chew [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, October 31, 2001 2:45 PM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] suggestion
>
>Hi
>
>Currently, in order to perform a long transaction update, you need to
turn
>cache on. Also, Castor uses the timestamp to check for a modifed
object.
>
>I have a suggestion/idea. For a long transaction object, it will hold a
>reference to a deep copy of itself, eg:
>
>public class Customer {
> public Customer originalCustomer; // Deep copy of itself during a
read
>}
>
>When an update is performed:
>
>(1) Castor loads the object from the DB
>(2) Loops through all the fields of the deep copy to make sure that no
one
>else has modifed the object
You need the cache to compare if the row in the database is modified or
not.
That's exactly why we need cache.
Thomas
>(3) If dirty, throw an exception, else perform update on new fields
>
>This will allow cache to be turned off, and the field comparison will
be
the
>safest check.
>
>Is this concept feasible or am I completely out of my mind? And is it
easy
>to add into Castor?
>
>Curious
>Keith C
>
>-----------------------------------------------------------
>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
-----------------------------------------------------------
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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
