On Thu, 01 Apr 2004 22:35:44 -0700, Bruce Snyder wrote:
>
>Nick Stuart wrote:
>
>> Hello all. I was just wandering about long transactions and cache
>> management. What's happening is that I'm loading a bunch of stuff up to
>> use/view in jsp pages. I load enough stuff up so that stuff gets bumped
>> out of the cache, which is fine until I try and go to update something,
>> then it gives me an ObjectModifiedException. Would there be a way to
>> update something that is not in the cache? I changed the cache-type to
>> unlimited so that nothing gets thrown out, but I would like to not to
>> have to store everything in memory if I can avoid it. I would use
>> lazy-loading but it needs to have the transaction or the database (?)
>> open for it to load the object which makes sense, but I close both when
>> I'm done doing something so that wont work. :/
>>
>> Here's the output of my log before I changed the cache-type:
>> 16:35:39,280 [main] DEBUG com.vort.help.tests - Ticket
>> 1286/1080855338898 loaded.
>> 2004-04-01 16:35:39,280 [main] DEBUG com.vort.help.commands - Starting
>> to update ticket.
>> 2004-04-01 16:35:39,280 [main] INFO com.vort.help.commands - Updating
>> ticket #1286/1080855338898 for user jbutler
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> com.vort.help.commands.UpdateTicketInfo - Updating all related ticket
>> information
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.Priority/2: com.vort.help.beans.Priority/2/17 -/-
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.Category/82: com.vort.help.beans.Category/82/137 -/-
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> com.vort.help.commands.UpdateTicketInfo - Updating the tech info for nstuart
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> org.exolab.castor.persist.cache.TimeLimited - TimeLimiteLRU:
>> remove(com.vort.help.beans.Employee/nstuart) =
>> com.vort.help.beans.Employee/nstuart/0 -/-
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.User/3: com.vort.help.beans.User/3/115 -/-
>> 2004-04-01 16:35:39,280 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.Department/11:
>> com.vort.help.beans.Department/11/1 -/-
>> 2004-04-01 16:35:39,290 [main] DEBUG
>> org.exolab.castor.persist.cache.TimeLimited - TimeLimiteLRU:
>> remove(com.vort.help.beans.Employee/jbutler) =
>> com.vort.help.beans.Employee/jbutler/117 -/-
>> 2004-04-01 16:35:39,290 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.User/15: com.vort.help.beans.User/15/136 -/-
>> 2004-04-01 16:35:39,290 [main] DEBUG
>> org.exolab.castor.persist.cache.CountLimited - Removing cache entry for
>> key com.vort.help.beans.Ticket/1286: null <<<<<------
>> 2004-04-01 16:35:39,290 [main] INFO com.vort.help.commands - There was
>> a problem updating the ticket: Timestamp mismatched!
>> 2004-04-01 16:35:39,300 [main] DEBUG com.vort.help.commands - StackTrace:
>> org.exolab.castor.jdo.ObjectModifiedException: Timestamp mismatched!
>>
>> <<<<<----- I looked through the source and saw that this was supposed to
>> be the removedObject from the cache, so apparently this wasn't there to
>> be removed and hence complains. Maybe a better exception here would
>> be ObjectNotInCache or something like that. I spent hours trying to
>> figure where my timestamp issues were because I didn't have the castor
>> logs on debug mode :(
>
>A good suggestion for clarification.
>
>> And basically I guess I want to know is, why does an object have to be
>> in cache in order to update it? Couldn't it get reloaded if it wasn't in
>> the cache and then update it?
>
>I just asked myself the same question. We'll need to let Werner chime in
>here as he has made some changes to the caching lately.
As explained in my previous reply to Nick, all my changes focused on reworking the way
performance cachges are structured internally (subclassing vs-
subtyping), initialization, configuration, etc. For those interested, please visit
bugs 1532, 1533 and 1534 and let me know what you think.
> I intend to help
>him with the caching very soon as I'm intending on working on the
>caching in Geronimo soon as well.
>
>I'm not quite sure where the dirty
>> checking comes in but I'm guessing this is why things need to be in the
>> cache to in order to be updated....is this right?
>
>I can't recall off the top of my head. I'd need to debug a bit to wrap
>my head around it again. But that's probably a good guess. Let's hear
>from Werner before I debug it myself.
>
>Bruce
>--
>perl -e 'print
>unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
>The Castor Project
>http://www.castor.org/
>
>Apache Geronimo
>http://incubator.apache.org/projects/geronimo.html
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
