Re: Can someone explain the locks?
Re: Can someone explain the locks?
- Subject: Re: Can someone explain the locks?
- From: "Ruenagel, Frank" <email@hidden>
- Date: Thu, 12 Jan 2012 19:01:28 +0100
- Thread-topic: Re: Can someone explain the locks?
Yeah, MSSQL is definitely one of these databases. IIRC, it is a problem of the default MS plugin. James, do you use SQL-Server with the default MS Plugin of WO?
But also I think that the problem is not an optimistic locking problem. James, if you do not have access to the userInfo of the exception, simply remove all
locking-symbols in the Entity in EO Modeler (include the entities joined). Rebuild. Does the exception appear again? If yes then it is *not* due to opt locking.
"Optimistic Locking" in standard EOF is simply realized with a where clause in the update sql-string: the values expected are compared with the real data in the rows.
It could be helpful to view the sql code, which is sent to your database while updating.
Switch on logging of the sql with :
NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupDatabaseAccess);
Then try to execute the logged sql manually.
Good luck.
Frank
Von: webobjects-dev-bounces+webobjects=email@hidden [mailto:webobjects-dev-bounces+webobjects=email@hidden] Im Auftrag von Ramsey Gurley
Bereitgestellt: Donnerstag, 12. Januar 2012 17:26
Bereitgestellt in: WebObjects
Unterhaltung: Can someone explain the locks?
Betreff: Re: Can someone explain the locks?
A date time is actually a bad attribute to lock on some databases. Timestamps have nanosecond resolution, but some databases are not that accurate. So you end up with a value that is slightly off from what is stored resulting in locking exceptions. I think MSSQL is one of these databases.
But to get to your point, yes you can do that. Locking says that this attribute value is important. If you lock a single column and update it every time you save in willUpdate() you're saying that ALL attribute changes are important.
However, you then become dependent on application logic doing that. If someone comes in and edits values with a DB tool and does not increment the 'version' column, then those changes can get wiped out by a save from the app.
In your case, unless it's the timestamp thing, I don't *think* locking is your problem, because you're the only person editing the data. When you get the exception, if you do a select in the database with the qualifier values, does it return the row? If it does, then it's probably not a locking exception.
Ramsey
On Jan 12, 2012, at 9:11 AM, James Cicenia wrote:
Ok --
So, why would I need more than one lock? Why not just a modified date?
James
PS: "legacy" Been awhile since I have been to apples docs. Not a good thing to first show a client!
On Jan 12, 2012, at 9:51 AM, Ramsey Gurley wrote:
On Jan 12, 2012, at 8:33 AM, James Cicenia wrote:
Hello -
Ok, this update / add entity problem is driving me a little nuts.
If I add a new record, it won't recognize the related record that was picked, and won't save.
If I edit any existing record and do nothing but hit save... bam.. row diff error!
So, that got me to exploring those little black locks that I never, ever worried about, or changed!
But now that I have focused on them.. what the heck do they really mean or do?
http://developer.apple.com/legacy/mac/library/documentation/WebObjects/UsingEOModeler/4WorkingWithAttributes/WorkingWithAttributes.html#//apple_ref/doc/uid/TP30001018-CH204-BABBDEIE
If I save a record
it should save.. locks be damned. So, I figured it has to do with "optimistic" locking. But what?
Should I leave the default set? Should I delete all and improve performance?
Wondering
James _______________________________________________
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
_______________________________________________
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
_______________________________________________
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