Fair enough. I'll try rewriting all my code in terms of SelectQuery and
see what kind of performance I get. The remaining issue, though, is the
caching component.
In case you forgot it goes something like this:
ImageCacheManager [num_requests, num_hits]
ImageCacheEntry [score, originalImageId, cachedImageId]
On every cache hit ImageCacheManager.num_requests will be incremented.
The implication is that only one client may use the cache at a time. We
had suggested I bypass optimistic locking using SQLTemplate "update
ImageCacheManager set num_requests = num_requests+1" and then refresh
the object state thereafter. I guess I'm still stuck doing this right?
There is no better workaround?
Thanks,
Gili
Andrus Adamchik wrote:
>> If this request does not make any sense, please let me know why
>
>
> I think you are still trying to make Cayenne go Hibernate way...
>
> While I can give an answer to your specific question (not a one- liner,
> but something that would behave like you expect), I'd still recommend
> you to try deletion via the object layer (i.e. fetch, analyze and delete).
>
> You are trying to go the opposite way - delete and then fetch to
> synchronize cache. So whatever performance boost you'd get from raw sql
> deletion, would be reversed later when you do syncing (Imagine - you
> deleted 5 objects and then have to re-sync a few thousands objects ...
> there is no free lunch).
>
> Also you can improve the performance of select in a number of ways (see
> performance tuning in the User Guide).
>
> Andrus
>
>
>
> On Sep 5, 2005, at 11:47 PM, Gili wrote:
>
>> Gili wrote:
>>
>>>> Umm, yeah - context.invalidateObjects(dataContext.getObjectStore
>>>> ().getObjects())
>>>>
>>> Ok, so invalidateObjects() does not actually dump the object
>>> state then? I was under the impression it removes any modifications
>>> that occured since the DB instance was originally retrieved.
>>>
>>
>> I looked up the Javadoc again and it seems I was right.
>> invalidateObjects() discards any modifications. This is not what I
>> was asking for. I'm looking for a method which will re-read any
>> unmodified attribute but not clobber any modified ones. If this
>> request does not make any sense, please let me know why :P
>>
>> Gili
>
>
>
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Tue Sep 06 2005 - 00:34:58 EDT