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
