Re: [castor-dev] updating when not in cache...

[Nick Stuart]

Heh, ya but right now I'm taking 6 classes and working for 30+ hours of 
week at a "real" job, so my time has been strained to say the least 
(have always worked through all 4 years of college).
But anyways, I hope to at least start reading through the code to find 
out whats going on where and start to piece things together. I think by 
running across the problems I am now will help with a better 
understanding of stuff once I get into it. *at least I hope it will :) *

Werner Guttmann wrote:

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

 

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
       unsubscribe castor-dev