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).
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.
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.
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Monday, August 29, 2005 10:24 AM
To: cayenne-use..bjectstyle.org
Subject: Re: Lazily column retrieval
I could do that but it would cause consistency issues. For one,
I don't
want the image_cache_stats table to update if the image_cache failed to
update. I need a transaction to wrap the entire operation to ensure it
fully goes through or not.
Secondly, the way the algorithm works, if I try adding a cache
entry to
the pool and find out it is full I am supposed to discard the entries
with the lowest score. This requires me to update all rows in the table
(to update their individual scores) and then issue a query sorting them
in ascending score (to remove the lowest score entries first). When this
operation occurs, it pretty much requires me to lock the entire table
because all entries will be touched.
I am pretty sure I could update their scores one a time without
many
collisions but updating *all* their scores within a single transaction
is almost guaranteed to encounter collisions. I'm not sure it makes
sense to create a new transaction per row I update; this seems a bit
overkill.
Gili
Gentry, Michael (Contractor) wrote:
> That's way too much for me to read through right now ...
>
> For your image_cache_stats table, two things come to mind:
>
> 1) If your database supports it, you could write a stored procedure to
> begin a transaction, update the values, and return them back to
Cayenne.
>
> 2) Use SQLTemplate to send an UPDATE statement (something like: UPDATE
> image_cache_stats set num_requests = num_requests + 1) and then do a
> query to read the values back in again (if you need them at that
point).
>
> I'm not certain how your image_cache table functions, but a similar
> approach might be sufficient for that, too. This is far simpler than
> adding pessimistic locking to Cayenne and should perform better, too.
>
> /dev/mrg
>
> PS. You could also use SQLTemplate to do a SELECT ... FOR UPDATE (to
> lock the row), too. Just be sure you release the locks. Be
especially
> careful to use a try/catch/finally around everything you do and in the
> finally clause, release the locks. Otherwise if there is an
exception,
> deadlocks will get you.
>
>
> -----Original Message-----
> From: Gili [mailto:cowwo..bs.darktech.org]
> Sent: Monday, August 29, 2005 8:56 AM
> To: cayenne-use..bjectstyle.org
> Subject: Re: Lazily column retrieval
>
>
>
> I've implemented the algorithm found here
> http://www.usenix.org/events/usits99/full_papers/bahn/bahn_html/
>
> I've got two tables:
>
> image_cache_stats, which contains [num_requests, num_hits]
> image_cache, which contains cache entries [score, time, cachedImage]
>
> In a typical request, num_requests is incremented, and a few
> entries
> might be added or removed from image_cache. If multiple clients try
> hitting the cache at the same time with optimistic locking they will
> always collide because num_requests is being incremented by every
> client. If you've got an idea for improving on this I'd be more than
> glad to try it!
>
> Thanks,
> Gili
>
> Gentry, Michael (Contractor) wrote:
>
>>Gili, why is it that you need pessimistic locking over optimistic
>>locking? In other words, what is your use-case? I'd be hard-pressed
>
> to
>
>>come up with a situation where I'd prefer pessimistic locking.
>>
>>Thanks,
>>
>>/dev/mrg
>>
>>
>>-----Original Message-----
>>From: Gili [mailto:cowwo..bs.darktech.org]
>>Sent: Saturday, August 27, 2005 3:41 PM
>>To: cayenne-use..bjectstyle.org
>>Subject: Re: Lazily column retrieval
>>
>>
>>Hi Andrus,
>>
>> You're one of the main developers of Cayenne if I remember
>>correctly :)
>>Could you possibly help me add pissimistic locking support to Cayenne?
>
>
>>I've got a use-case that requires it.
>>
>> I'm hoping to add both pissimistic locking and streaming BLOBs
>>to the
>>next release but I am new to Cayenne so I don't know where exactly to
>>start.
>>
>>Thanks,
>>Gili
>>
>>Andrus Adamchik wrote:
>>
>>
>>>I haven't heard of anyone posting a streaming [C|B]LOB ExtendedType.
>>
>>A
>>
>>
>>>generic implementation would require some thought, but a simplified
>>>read-only custom version should be pretty easy to make.
>>>
>>>Reading blobs is much easier that writing them. Just implement
>>>"getClassName()" to return "java.sql.Blob" and "materializeObject
>>
>>(..)"
>>
>>
>>>to call "getBlob()". Don't recall if some DB's (Oracle?) required an
>>>open connection that created a BLOB for the BLOB object to be
>>>accessible. If this is the case, I can think of a few workarounds
for
>>
>>
>>>that.
>>>
>>>If you are going to try it and willing to share your code, please
>>>attach to CAY-316.
>>>
>>>Thanks
>>>Andrus
>>>
>>>On Aug 27, 2005, at 1:05 AM, Gili wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>> I'm looking for something similar to http://objectstyle.org/
>>>>jira/secure/ViewIssue.jspa?key=CAY-316 which will allow me to
lazily
>>
>>
>>>>retrieve certain blob columns. I was told someone on this list
might
>>
>>
>>>>already have an ExtendedType which does this?
>>>>
>>>>Gili
>>>>--
>>>>http://www.desktopbeautifier.com/
>>>
>>>
>>>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 11:22:11 EDT