Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: Mike Schrag <email@hidden>
- Date: Fri, 20 Jan 2006 14:42:51 -0500
Sure -- I can put it up if nobody minds a class where everything is
named "Test" and has vars like "a" and "b" in it :) Basically,
you're not allowed to pass judgement on me based on this project ...
This is a WOLips 2.(latest) project and depends on Project Wonder
(thought the wonder dependency is tiny -- i just build all my
projects with it at this point).
http://www.mdimension.com/LockingTest.zip
ms
On Jan 20, 2006, at 1:21 PM, Arturo Perez wrote:
Mike Schrag wrote:
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
Interesting. Can you make the code freely available so we can all
test?
-arturo
_______________________________________________
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