> 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
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 11:37:16 EDT