I'm not certain that would work: your DB would have to support nested
transactions as would Cayenne (since commitChanges() will start a
transaction).
A safer way might be:
add/remove cache entries using object queries (might fail, catch
exceptions)
increment num_references using SQLTemplate (highly unliked to fail)
However, I think my previous suggestions (CacheHelper) would make the
most sense.
I'm not certain if there is a way to control OL on a per-query basis
(haven't had a need to look into it).
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Monday, August 29, 2005 1:24 PM
To: cayenne-use..bjectstyle.org
Subject: Re: Lazily column retrieval
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:18:01 EDT