John, That's odd, as you should not get exceptions related to objects having expired from an unlimited cache. Are you still in a position to reproduce this ?
Regards Werner Guttmann > -----Original Message----- > From: John Greene [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 21. Februar 2006 10:25 > To: [email protected] > Subject: RE: [castor-user] BIGINT Support in Castor > > Hi Werner, > > Yes, thanks for the clarification. The documentation gives you four > options: no cache, count-limited, time-limited and unlimited. > I had actually set the cache-type to the latter, unlimited. > > Anyway, thanks again. > > John > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 03:29 AM > To: [email protected]; [EMAIL PROTECTED] > Subject: RE: [castor-user] BIGINT Support in Castor > > > Thanks, John, for letting us know that you managed to solve > your problems. Having said that, let me just address one of > the issues mentioned below. As shown in the documentation for > "long transactions", one needs to implement the TimeStampable > interface to be able to use successfully e.g. the > Database.update() method (which is what you have done). > > Internally, Castor needs to remember any object (that implements > TimeStampable) that has been loaded as part of a transaction, > so that it can check for any modifications to its content > when passing this object to Datbase.update(). For this task, > Castor JDO uses its caches. This implies that the (original) > object in question should be available in the caches when > performing the Database.update(). Unfortunately, there's > cache types like 'count-limited' and 'time-limited' where > this might not be the case, as the object might be dropped > from the cache as a result of the cache's policy. Please note > that using no cache at all defaults to using a > 'count-limited' cache with an initial size of 100 (I believe). > > I hope this clarifies a few things related to the use of long > transactions. > > Regards > Werner > > > ________________________________ > > From: John Greene [mailto:[EMAIL PROTECTED] > Sent: Montag, 20. Februar 2006 22:50 > To: Castor User > Subject: FW: [castor-user] BIGINT Support in Castor > > > I was able to sort this issue. > > When you implement TimeStampable two methods need to be > overidden: > > public void jdoSetTimeStamp(long l) > { > setTimeStamp(l); > } > > public long jdoGetTimeStamp() > { > return getTimeStamp(); > } > > > Since the runtime error message was complaining about > the getTimeStamp method not available, I add two additional methods: > > > public long getTimeStamp() > { > return timeStamp; > } > > public void setTimeStamp(long _timeStamp) > { > this.timeStamp = _timeStamp; > } > > Another issue was that I had defimed in my Mapping > Table the IDENTITY as "BookTitle" as Varchar. > > If I wanted to change the book title I got another > titel, using the UPDATE command I got a runtime error > relating to the TimeStamp no longer in cache. But this is no > longer a problem since I load the object and apply the commit command. > > regards > John. > > > > -----Original Message----- > From: John Greene [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 12:16 PM > To: [email protected] > Subject: RE: [castor-user] BIGINT Support in Castor > > > Hi Werner, > > Yes, I agree that it should work as is. > > I'd like to run a few more test at my end first; if I > continue to hit a "brick wall" I'll raise a new issue. > > regards > John > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 02:44 AM > To: [email protected]; [EMAIL PROTECTED] > Subject: RE: [castor-user] BIGINT Support in Castor > > > John, > > That should work out of the box. Can you please > - as already indicated - open a new issue at > http://jira.codehaus.org/browse/CASTOR and attach a stripped > down sample that shows your problem. > > Thanks > Werner > > > ________________________________ > > From: John Greene [mailto:[EMAIL PROTECTED] > > Sent: Dienstag, 14. Februar 2006 22:32 > To: [email protected] > Subject: RE: [castor-user] BIGINT > Support in Castor > > > Thanks for the input. > > I am implementing "TimeStampable" which > returns a type "long". > > > public class Student implements TimeStampable > { > ......... > > public void jdoSetTimeStamp(long l) > { > timeStamp = l; > } > > public long jdoGetTimeStamp() > { > return timeStamp; > } > } > > > As you have said derby support "bigint" > not "long" data type. But in my mapping file I did the > mapping as follows:.......... > <field name="timestamp" type="long"> > > <sql name="timestamp" type="bigint"/> > > </field> > > John. > > -----Original Message----- > From: Brian Schlining [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 14, 2006 12:07 PM > To: [email protected] > Subject: Re: [castor-user] BIGINT > Support in Castor > > > > I have a castor app that I've > tested against both Derby and SQL Server. All the primary > keys are bigints and the app works fine against both > databases. The Castor mapping can be found at > > http://cvs.sourceforge.net/viewcvs.py/vars/vars/resources/conf > /annotatio > n_mapping.xml?view=markup > > > The derby DDL is at > http://cvs.sourceforge.net/viewcvs.py/vars/vars/src/sql/derby/ > vars.ddl?v > iew=markup > > > Cheers > B > > > > Hi Werner, > > Quick question, does Castor > support the sql type "BIGINT "? > > My Derby database uses type > "BIGINT" intead of "long" > > Reported Run-time error: > > org.exolab.castor.mapping.MappingException: Nested error: > > org.exolab.castor.mapping.MappingException: > The SQL type BIGINT is not > supported in this release > > > > > > > ------------------------------------------------- > If you wish to unsubscribe from > this list, please > send an empty message to the > following address: > > > [EMAIL PROTECTED] > > ------------------------------------------------- > > > > ~ ~ ~ ~ > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > MBARI > Software Engineer > [EMAIL PROTECTED] > (831)775-1855 > http://www.mbari.org/staff/brian > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
