No, Cayenne isn't "smart" enough to automatically generate an
incrementing SQL statement, but you are. :-) I don't know of any ORM
that is smart enough to check for that. And, personally, I think it
would be a performance drag to add it.
I wasn't suggesting locking on a database object. Make a CacheHelper
class which you use exclusively to manipulate the cache. Use Java
synchronization (on a method or variable, whichever makes more sense in
your helper class) to ensure only one thread is monkeying with the cache
at any point in time. If you do this, you should be able to use plain
old Cayenne DataObjects and fire a single commitChanges() to do it all
in one transaction. You might not even need SQLTemplate with this
approach. The more I think about it, this might be the simplest
solution and will ensure you don't have cache manipulation code
scattered about.
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Monday, August 29, 2005 11:37 AM
To: cayenne-use..bjectstyle.org
Subject: Re: Lazily column retrieval
> 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 - 14:12:40 EDT