I haven't done any timings, but I find it hard to believe that this technique will effect any significant savings for most databases. As Art indicates, the only effect of reducing the number of lock columns is to correspondingly reduce the number of columns in the WHERE clause for updates and deletes.
I've always wondered this, too, so I threw together a quick test.  I created two identical entities which have 3 ints, 3 booleans, 3 strings, and 3 dates as properties, but one locks all attrs and one locks none.  I then inserted 10,000 of each into the db, followed by an update of the same attribute for each with the same change in value.

This was run on the latest version of FrontBase on an Intel iMac with WO 5.3:

Main.main: 10000 with all columns locked = 25753ms
Main.main: 10000 with no columns locked = 7111ms

So in this test, it is 3.6x faster to not lock any columns in this example, with this database, one this hardware.  Obviously db benchmarks are never this simple, so take this with a grain of salt.

ms

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to