Well, to avoid integrity issues or update failures, you really need a
common control mechanism for a shared (and changing) resource, otherwise
you are on a slippery slope.
I suspect you are using MySQL, so a stored procedure is out of the
question? (I've not looked at MySQL in a while, so I don't know if that
is possible now).
You could write a web service (or similar) which managed the cache and
direct all requests to it. Probably too much work.
You could turn on Cayenne's Remote Change Notification (under the Data
Domain's Cache Configuration) and use a CacheManager as I mentioned
before. I've not used that mechanism before, so perhaps someone else
could comment on it.
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Monday, August 29, 2005 2:23 PM
To: cayenne-use..bjectstyle.org
Subject: Re: Lazily column retrieval
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 - 15:29:26 EDT