Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: "Jerry W. Walker" <email@hidden>
- Date: Fri, 20 Jan 2006 09:57:34 -0500
On Jan 19, 2006, at 5:53 PM, Art Isbell wrote:
#1. Review your EOModel and make sure you are locking only on
columns you need to. On fresh applications I've always put in a
dateLastUpdated column in each object and lock only on that.
This will accelerate updates and deletes because the generated
"WHERE" clause will contain each column whose attribute is used for
locking plus the primary key columns. By locking only on
dateLastUpdated, the number of columns for which the database must
compare values is minimized.
However, beware of precision problems that can exist with some
databases when using timestamp attributes for locking. These
problems will cause update and delete failures that don't make sense.
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.
So on an update, the record to be updated will be found based on its
indexed PK, then the database will internally compare the value of
each field in the one record to be updated that corresponds to that
field in the WHERE clause. How much time can this take? Has anyone
ever measured the savings of reducing that number of fields for that
one record?
I would guess that the greatest overhead would be in generating the
additional SQL name/value pairs by WO or in communicating those extra
WHERE clause bytes to the database, and I would further guess that
the entire additional overhead would be in the sub 10 millisecond
range for a record with fewer than, say, 20 locked fields. For
records with upwards of 100 locked fields, I would be less confident
about the lack of savings but would wonder at the degree of
normalization for that entity.
I don't feel quite so confident about the insignificance of the
savings for the delete in which multiple records can be deleted by
the same delete statement. But I still feel that the overhead saved
by reducing the number of those fields is negligible for most
applications, even where a fairly substantial number of records is
being deleted.
My point is not so much to opine on these savings as to ask if anyone
has done any timings on any of the modern databases to confirm that
this "technique for economy" really saves anything significant.
Regards,
Jerry
--
__ 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