On Fri, 2 Apr 2004 08:12:37 -0500, Nick Stuart wrote: > >Thanks for your replies, both Werner and Bruce. I'll add a enhancement bug to >bugzilla for the exception and take a look at those other bugs as well. Everything you state makes sense, I know all about re-using stuff once its already been coded...even if there is a better way around it :) >But, at least the good news is that it is getting worked on and upgraded which is >really cool to hear! >At some point, when I'm done with college (last semester, woohoo!) and all I have to >worry about is work I'm going to start >poking around in castor a lot more to see what damage I can do. :) Interesting comment ... looking back sort of eight years, it now appears to me that I never ever had so much time at my fingers as back when I was finishing my master degree. Iow, feel free to start digging now ... spare time will decrease sharply once you hit the market ... ;-).
Werner > >Thanks again for the replies and clarification. > >-Nick > >P.s. And no more html message will pass your way, I swear! > >-----Original Message----- >From: Werner Guttmann [mailto:[EMAIL PROTECTED] >Sent: Friday, April 02, 2004 6:22 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] updating when not in cache... > > >Nick, > >if I ever see an email with HTML code again, I am not going to respond anymore ... >;-). Just kidding, of course. > >Please see inline for (tentative) replies ... > >Werner > >--Original Message Text--- >From: Nick Stuart >Date: Thu, 1 Apr 2004 17:13:21 -0500 > >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. > ><werner > >well, as you've discovered yourself, for long transactions to work, an object >previously loaded in an earlier transaction context needs to be in cache for >Database.update() to work. I do agree that this is not ideal and hence should be >changed. And to give you a nice and warm feeling about the future, it will be changed (eventually). I am currently reworking major parts of the performance caches (details to be found in bugs 1532, 1533 and 1534), and I am making some progress, indeed. But so far, my focus has been on refactoring the performance caches wrt their internal structure (subclassing vs. >subtyping), instantiation, configuration. Iow, I have not touched on the subject of >decoupling performance cache(s) from dirty checking cache. As that's what you are currently suffering from. When this has been implemented originally, a decision has been taken to 're-use' the performance caches .. not an ideal one, though. > >I think long-term, all this will have to be addressed. In the short term, I agree >that a couple of things could be done re: throwing a different exception, etc. >For the time being, I thin you'll be stuck with either using Unlimited or >CountLimited with a carefully selected capacity. ></werner> > >Would there be a way to update something that is not in the cache? > ><werner> as per above, no. </werner> > >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 :( > ><werner>I agree that something should be done about the exception thrown ... please >feel free to file a bug report (enhancemenbt request), and I'll take a look ... as always, an associated patch would be welcome as well.</werner> > >And basically I guess I want to know is, why does an object have to be in cache in >order to update it? > ><werner>'casue that's the chosen mechanism to store the timestamp information >associated with the object when it has been loaded in a previous transaction context. as explained above, the performance caches have veen 're-used'when they should not have .. ;-). I hope this explains why things are occuring as they are. Of course, my explanation still fails to make the problem go away ...</werner> > >Couldn't it get reloaded if it wasn't in the cache and then update it? 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? > >Nicholas Stuart >Computer Systems Analyst > >Vortechnics, Inc. >200 Enterprise Drive >Scarborough, Maine 04074 > > > > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004 > > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004 > > >--- >Outgoing mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004 > > >----------------------------------------------------------- >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
