ack. subclass Query and override UsingOptimisticLocking() -- can't
guarantee it will work, but I think it will.
On 8/29/05, Mike Kienenberger <mkienen..mail.com> wrote:
> 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:27:10 EDT