Re: Optimistic locking solved... nearly
Re: Optimistic locking solved... nearly
- Subject: Re: Optimistic locking solved... nearly
- From: Art Isbell <email@hidden>
- Date: Sat, 3 May 2003 13:36:07 -1000
On Saturday, May 3, 2003, at 12:29 PM, Gino Pacitti wrote:
I had a attribute which is External type of TIMESTAMP and Internal
type of Date
From the NSTimestamp JavaDoc:
"The Enterprise Objects Framework expects dates to be represented as
NSTimestamp objects. To convert a java.util.Date to an NSTimestamp use:
NSTimestamp myNSTimestamp = new NSTimestamp(myJavaUtilDate);
Since NSTimestamp is a subclass of java.util.Date, you don't need to
convert an NSTimestamp into a java.util.Date."
I replaced all the locks and left the lock off the attribute that had
the TIMESTAMP
It then still updated and all worked well.
Why does Optimistic Locking fail on this type of attribute?
If it still occurs when you change the internal type to NSTimestamp,
you might be running into a bug in the database plugin or in a
round-off error. Many databases store NSTimestamps down to millisecond
precision. I have experienced a similar update problem when data in
the database was stored to milliseconds but the database plugin dealt
only to second precision which resulted in an EOF-generated "where"
clause always evaluating to false unless the stored timestamp was exact
to the second.
I usually include a "lastUpdate" attribute in each entity. lastUpdate
contains the timestamp of the last update. I use only this attribute
for locking which results in a "where" clause that is faster to
evaluate than one containing many attributes.
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.