Optimistic locking is currently on a per-object basis, but since the
status of whether any particular query does optimistic locking is
maintained as part of the query, it would be fairly simple to override
that behavior. It could either be another flag
(setShouldUseOptimisticLocking) or you could just subclass the
On 8/29/05, Gili <cowwo..bs.darktech.org> wrote:
>
> What about if I do this?
>
> begin transaction
> increment num_references using SQLTemplate
> add/remove cache entries using object queries
> end transaction
>
> This should ensure everything occurs from within a single transaction,
> while avoidding collisions for num_references. I assume that even if
> optimistic-locking is enabled for the table containing num_references,
> it'll be ignored if I use SQLTemplate?
>
> Basically I want to selectively increment num_references without any
> optimistic locking. The same goes for deleting cache entries. If I
> delete a cache entry and it has been modified since I last viewed it
> (i.e. its score changed) I expect the delete to go through anyway.
>
> Is there a way to control optimistic locking on a per-query basis like
> this? or am is it controlled on a per-table basis?
>
> Thanks,
> Gili
>
> Gili wrote:
> > > Well, sending an "UPDATE image_cache_stats SET num_requests =
> > > num_requests + 1" is highly unlikely to fail (your DB would have to
> > > tank, in which case there is nothing Cayenne can do).
> >
> > Regarding "UPDATE image_cache_stats SET num_requests = num_requests
> > + 1" I am curious whether Cayenne is smart enough to issue this SQL
> > statement itself or is it impossible for it to know whether I am
> > incrementing a field versus setting it to an explicit value?
> >
> >> Are you trying to limit the image_cache_stats to a set size? You could
> >> do that, adding new entries and deleting others and then do a
> >> dataContext.commitChanges(), but that seems like more trouble that it is
> >> worth.
> >>
> >> Could you not leave old entries in the image_cache_stats table do a
> >> query against it with an ORDER BY and a LIMIT to control the data coming
> >> back? I'd let the database do the work since it is good at it. If you
> >> did have a need to prune the size of the table, you could always issue a
> >> DELETE using SQLTemplate to get rid of rows that fall below a certain
> >> threshold.
> >
> >
> > That would work too but it won't guarantee the cache size is less
> > than a certain value. I *almost* do what you say though. I do ORDER BY
> > and remove rows I get back until the total cache size is under its
> > expected limit.
> >
> >> I guess what I'm saying is don't be afraid to use an SQLTemplate when
> >> you have a valid need for it (that's what I do when it makes sense).
> >> Let the database do work for you when appropriate.
> >>
> >> As for the consistency issue, as soon as you refetch the table data,
> >> you'll be up-to-date again in Cayenne. It might make sense to put all
> >> of this logic in a helper class (complete with it's own DataContext) to
> >> manage it. You should use a synchronize block around the update code to
> >> let Java serialize that portion.
> >
> >
> > But this still does not guarantee consistency. If I use two separate
> > transactions: one for incrementing num_requests, and another for
> > actually inserting/removing cache entries, there is no guarantee both
> > will succeed or fail together.
> >
> > Secondly, in the Hibernate documentation they explicitly warn not to
> > sychronize on database objects in memory because this does not guarantee
> > they won't actually get modified. The only safe place to lock on objects
> > is in the database. In Hibernate, for example, each thread sees a
> > difference object instance which points to the same database row.
> > Synchronizing in one piece of code in one application will not prevent
> > another piece of code in another application will attempting modification.
> >
> > Gili
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 14:24:43 EDT