I've been looking through the code today for the proper place to put in
optimistic locking. As a first pass, I'm considering locking on every
dbEntity and every dbEntity dbAttribute. This avoids changing my model and
changing the model data structure as well as problems with objAttributes
with no direct dbAttribute mapping.
My first thought was to do something along the lines of
DataContextDelegate's willPerformSelect() named willPerformUpdate() and just
add it into my DataContextDelegate, but I wondered whether I was attacking
the problem at too high a level since any support here would only be for
optimistic locking WHERE clauses.
So my second idea was to put it in createSqlString for the following three
classes.
UpdateTranslator
UpdateBatchQueryBuilder
LOBUpdateBatchQueryBuilder
I still think that's where the real locking code has to go. However,
examining that code really showed that the proper handling of optimistic
locking would probably be easiest by generating more Query qualifiers rather
than trying to build equivalent expressions from scratch while merging with
existing qualifying query clauses. So I could either go back to
willPerformUpdate() or take a look at what invoked createSqlString for
updates.
That lead me to DataNode's runBatchUpdate's Query.UPDATE_QUERY switch
statement. Currently it's only used for selecting a
UpdateBatchQueryBuilder object. However, that location could also be used
to modify the query to add in support for additional optimistic locking
queries. Since this doesn't really provide support for anything other than
optimistic locking qualifier clauses, there's little point in doing it here
rather than in a DataContextDelegate. Adding willPerformUpdate() can be
used for other functionality in addition to supporting optimistic locking,
so that's where I think I'm going to make my first pass at this until
convinced otherwise.
-Mike
This archive was generated by hypermail 2.0.0 : Tue Feb 03 2004 - 16:29:23 EST