Heya folx - my setup: ORACLE 9.2, Castor 0.9.4, using sequences. my prob1: invalid timestamp on db.update() my prob2: oracle sequences w/db.update()
I'm new here, but I did want to chime in that I *too* have been having long transaction problems - particularly with update and the engine mistaking an object that already exists in the db as not existing... exceptions = a duplicate id, or invalid timestamp. I'd like to go on the record that I have problems with ID primitives too - I found this note thankfully and by switching from 'int' to 'Integer', it seems to have resolved the issue. I'm curious whether the null assignment (as compared to a literal primitive assignment for int) makes any difference. I typically have set the id = -1 for objects not yet created... Anyway, the change to Integer fixes my issues for invalid timestamp. Whether it resolves the issue of oracle & sequences, we shall see. So far, it doesn't look like it has fixed that issue. Chris Tue, 29 Oct 2002 18:43:45 +0100, you wrote:
----------
* Date: Tue, 29 Oct 2002 18:43:45 +0100
* From: Thomas Klute <<mailto:klute@;DOMAIN.HIDDEN>klute@xxxxxxxxx>
* Subject: Re: [castor-dev] Long transactions involving primitive identity field:ObjectModifiedException: Invalid object timestamp detected.
----------
Hi,
I encountered the same exception during a long transaction in a
castor0.9.4 + jboss-3.0.3_tomcat-4.1.12 + castor-jdo-plugin for Version 3.0 Environment.
I'm using a stateless session bean ( I modified the rooms2-example provided
on the jboss-page ) and I'm getting the same exception with my dao's as Ruslan
reported below. Changing the id from 'int' to 'java.lang.Integer' in the mapping and
in the bean fixed the error and all works well.
Currently I have little time for testing this, but pherhaps it would be interesting
if the rooms2 Example shows the same behaviour if the identities are set to 'int'
(currently Strings are used for identity).
Bruce, could this test be helpful?
Regards,
Thomas
Bruce Snyder wrote:
> This one time, at band camp, Ruslan Gainutdinov said:
>
> RG>I have a long transaction where in one thread, at some point of time I load
> RG>object from database. Then at server`s shutdown (or at object cache flush -
> RG>my own cache, not castor`s) I db.update() those objects, sequentially.
> RG>
> RG>I get following exception:
> RG>org.exolab.castor.jdo.ObjectModifiedException: Invalid object timestamp
> RG>detected.
> RG> at
> RG>org.exolab.castor.persist.ClassMolder.update(ClassMolder.java:2028)
> RG> at org.exolab.castor.persist.LockEngine.update(LockEngine.java:638)
> RG>
> RG>If I do the same thing, load in one db.begin()/db.end(), and update in
> RG>other, during one servlet doGet() session - everything goes fine.
> RG>
> RG>If I change so getId(), setId() methods accept not primitive type int, but
> RG>object java.lang.Integer - everything starts working fine.
> RG>
> RG>Where should I dig on this matter? Is primitive identity fields fully
> RG>supported? Because, I understand, there is a way to distinuguish with
> RG>java.lang.Integer, do we have identity field or not - field will be null if
> RG>we don`t. But with primitive type there is always some value, -1, 0, 1....
> RG>and no way to say which of them is no-identity.
>
> Ruslan,
>
> Primitive identities are supported just fine in Castor. I've never
> heard of this type of problem with Castor. Please explain further your
> question about the use of a java.lang.Integer and no way to distinguish
> do we have an identity or not. I'm not sure, but you may have hit upon
> something here.
>
> I'm also curious to know how you're using your own cache with Castor. Are
> you simply disabling Castor's cache in the mapping descriptor and manually
> calling your own cache implementation? If not, please explain more and
> post your mapping and the relevant client code.
>
> Bruce
> --
>
> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.410 / Virus Database: 231 - Release Date: 10/31/2002
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.417 / Virus Database: 233 - Release Date: 11/8/2002
