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 - 10:23:37 EDT