• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Optimistic locking failure on insert
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimistic locking failure on insert


  • Subject: Re: Optimistic locking failure on insert
  • From: "Jerry W. Walker" <email@hidden>
  • Date: Wed, 15 Mar 2006 10:31:09 -0500

Hi, Ian,

I can't imagine (short of a bug in the development environment) how the code you're exposing below could cause an optimistic locking failure. The upshot of the code below only reads from the store. It neither creates nor updates any records therein.

Optimistic locking failures occur on an attempt to write a record to the database when the record on the database into which you're trying to write has data other than what you expected to be there. This is typically caused by someone else writing into the same record before you, but can also be caused by rounding errors in fields your checking for the optimistic locking check (e.g. including Doubles or Date fields among the optimistic lock check fields).

On Mar 14, 2006, at 11:54 PM, Ian Joyner wrote:

OK, found the problem. It was not in the model, but rather in the code for initializing a JTree. First, I was getting top-level nodes by getting them out of the display group:

NSArray notes = EOQualifier.filteredArrayWithQualifier (display_group.allObjects (), EOQualifier.qualifierWithQualifierFormat ("parent_note = null", null));

however, sometimes the display group had not fetched yet, so I used a fetch spec to go straight to the DB:

NSArray notes = editing_context.objectsWithFetchSpecification (new EOFetchSpecification ("Note", new EOAndQualifier (new NSArray (new Object [] {EOQualifier.qualifierWithQualifierFormat ("parent_note = null", null), EOQualifier.qualifierWithQualifierFormat ("owner = % @", new NSArray (new Object [] {owning_display_group.selectedObject ()}))})), null));

The above statement is more difficult to read than it needs to be. You can use "AND" directly in the qualifierWithQualifierFormat method.


For some reason, which I'd like an explanation for, this caused the optimistic locking problem when creating a new master record. So then I realised the most straight forward solution was to traverse the object path:

NSArray notes = EOQualifier.filteredArrayWithQualifier (((Artifact) owning_display_group.selectedObject ()).notes (), EOQualifier.qualifierWithQualifierFormat ("parent_note = null", null));

(The fetch spec code probably would have been better in Haskell, but I dislike assigning things to temporary variables in Java when the code could be more functional.)

I generally find that temporary variables can add greatly to the semantic value of the code. It can make the code significantly more readable. How does leaving them out make the code more functional?


Don't know if this little note may help anyone in the future, because I still don't know the link between the fetch spec and the optimistic locking failure (and I hate the hacking until it happens to work approach).

In looking over the debugging statements below, it looks like there is an attempt to save a member record which contains itself as a member. That is, it looks like the inserted record has the following recursive structure:


MemberRecord:
details = null
begin_date = 3/14/2006 @ 5:53:51 GMT
position = null
member = <self reference> ************ IS THIS CORRECT? ****************
end_date = null
group = Groups: {
<some not-yet-saved GroupMember>
}
person = null
title = <reference to previously saved title with PK = 1>
telephones = ()
modification_date = 3/14/2006 @ 5:53:51 GMT


I can certainly imagine problems with such a structure, if I'm inferring correctly.

Have you turned on EOAdaptorDebuggingEnabled to check the generated SQL? It looks like EOF may be attempting to write a record that contains itself recursively and determines on the second recursion that the record has already been written. That would be my guess without seeing the SQL.

Hope this helps.

Regards,
Jerry

Ian

On 14/03/2006, at 5:09 PM, Ian Joyner wrote:

I have been running this model for six months and saving this entity just fine. Suddenly, I am getting an optimistic locking failure when doing an insert of a new record (that's right insert, not update). In fact is the trace below, I show that the offending record is in the editing contexts insertedObjects and it has a EOTemporaryGlobalID which means it has not been written to the database yet.

No SQL commands are being executed in the SQL trace. I have turned off locking on every attribute for this entity in EOModeler. Other entities are still saving fine. So what's going on? How can I get around this problem?

[2006-03-14 16:53:56 EST] <AWT-EventQueue-0> xxx.client.Member_interface_controller save inserted ({values = {details = <com.webobjects.foundation.NSKeyValueCoding$Null>; begin_date = 2006-03-14 05:53:51 Etc/GMT; position = <com.webobjects.foundation.NSKeyValueCoding$Null>; member = "<com.sportstec.member.client.Member f1156e <EOTemporaryGlobalID: 0 0 -64 -88 0 7 0 0 -15 83 1 0 0 0 1 9 -9 81 65 -102 58 -107 -26 -116>>"; end_date = <com.webobjects.foundation.NSKeyValueCoding $Null>; group = "<com.sportstec.group.client.Group 47545b groups = ("<com.sportstec.group.client.Group_Member 8dacbb <EOTemporaryGlobalID: 0 0 -64 -88 0 7 0 0 -15 83 2 0 0 0 1 9 -9 81 65 -102 58 -107 -26 -116>>"); person = "null"; title = "<com.webobjects.eocontrol.EOGenericRecord dd1d62 _EOIntegralKeyGlobalID[Title (java.lang.Integer)1]>"; telephones = (); modification_date = 2006-03-14 05:53:51 Etc/GMT; }; this = "<com.sportstec.member.client.Member f1156e <EOTemporaryGlobalID: 0 0 -64 -88 0 7 0 0 -15 83 1 0 0 0 1 9 -9 81 65 -102 58 -107 -26 -116>>"; })

[2006-03-14 16:53:56 EST] <AWT-EventQueue-0> xxx.client.Member_interface_controller save updated (Gq)

[2006-03-14 16:53:56 EST] <AWT-EventQueue-0> xxx.client.Member_interface_controller save deleted ()

[2006-03-14 16:53:56 EST] <AWT-EventQueue-0> xxx.client.Member_interface_controller EditingContext saveChanges failed Server exception: Optimistic locking failure: The object with global ID <EOTemporaryGlobalID: 0 0 -64 -88 0 7 0 0 -15 83 1 0 0 0 1 9 -9 81 65 -102 58 -107 -26 -116> has been changed by another client

Thanks
Ian Joyner
Sportstec


--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems


    email@hidden
    203 278-4085        office



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Optimistic locking failure on insert
      • From: Ian Joyner <email@hidden>
    • Re: Optimistic locking failure on insert
      • From: Chuck Hill <email@hidden>
References: 
 >Optimistic locking failure on insert (From: Ian Joyner <email@hidden>)
 >Re: Optimistic locking failure on insert (From: Ian Joyner <email@hidden>)

  • Prev by Date: Re: Optimistic locking failure on insert
  • Next by Date: Re: Optimistic locking failure on insert
  • Previous by thread: Re: Optimistic locking failure on insert
  • Next by thread: Re: Optimistic locking failure on insert
  • Index(es):
    • Date
    • Thread