But... like I keep on saying... this doesn't help if the cache is
instantiated across different JVMs. In my case I have my webapp using
one JVM and my admin console using another and both hit the cache. In
the future I forsee clustering many other JVMs hitting the cache too. So
I don't see how locking in memory is going to help.
Gili
Gentry, Michael (Contractor) wrote:
> 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
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 14:22:36 EDT