[castor-dev] Release candidate for Castor 1.3

[Werner Guttmann]

Hi,

most likely, I will manage to make a first release candidate of Castor
1.3 available tomorrow night (my local time). I have just created a new
1.3rc1 release in Jira, to allow us tracking of regression issues
(should any arise .. ;-)).

In addition, I'd like to get an idea what work you (committers) like to
ship with 1.3 final. Personally, I'd like to spend most of my time on
documentation only between RC1 and GA, and I think the same should apply
for everybody.

So let's hear what exceptions you might be considering:

- Include the integration test case for the new JDO extensions for the
XML code generator (Werner).
- A few patches required to get the JAXB code moving again.
- New partial (pull) parsing module.

Regards
Werner

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Stephen Ince]

I am getting a "org.exolab.castor.jdo.ObjectModifiedException: Timestamp
mismatched!" error when saving a long transactions. How can I avoid this. I
have tried the following.

case 1:
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();

case 2:
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.

case 3:
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();

db.begin();
db.update(u);
db.commit();

Steve


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

Hi Stephen,

till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.

- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it

According to your test scenarios the second seams not to be the case
(case 2).

Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.

To prevent this you have to use cache type 'unlimited' or 'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.

If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.

- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database

If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/

Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. [phone]
Mobil: [phone]
Fax [phone]

Internet: www.syscon.eu
E-Mail: ***@syscon.eu

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Stephen Ince]

Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.

<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();



Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();


Steve
----- Original Message -----
From: "Ralf Joachim" <***@syscon.eu>
To: <***@castor.codehaus.org>
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or 'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

Hi Stephen,

there should be no need to reload the cached entities.

Regards
Ralf

Post by Stephen Ince
Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.
<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Steve
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or 'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Stephen Ince]

In order to do a long transcation the object has to be in the cache. Is
there anything I can do? In my case I am updating the object 60 seconds
later.


Steve

----- Original Message -----
From: "Ralf Joachim" <***@syscon.eu>
To: <***@castor.codehaus.org>
Sent: Tuesday, September 30, 2008 5:40 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
there should be no need to reload the cached entities.
Regards
Ralf

Post by Stephen Ince
Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.
<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or 'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

Sorry, I do not understand. Can you please explain what you want to
know. According to the last mail I thought things work now.

Ralf

Post by Stephen Ince
In order to do a long transcation the object has to be in the cache.
Is there anything I can do? In my case I am updating the object 60
seconds later.
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 5:40 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
there should be no need to reload the cached entities.
Regards
Ralf

Post by Stephen Ince
Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.
<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or
'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. [phone]
Mobil: [phone]
Fax [phone]

Internet: www.syscon.eu
E-Mail: ***@syscon.eu

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

If you refer on what or how to contribute to Castor: it's up to you what
you like most to work on. A good starting point is to check jira for
issues you like to work on. If you do not have time for deep code
analysis there are also some things you can do but they may not be very
intersting.

- cleanup checkstyle and compiler warnings (e.g. Java generics)
- write a howto on long transactions including persistence of timestamps
- help to migrate docs to docbook

Regards
Ralf

Post by Ralf Joachim
Sorry, I do not understand. Can you please explain what you want to
know. According to the last mail I thought things work now.
Ralf

Post by Stephen Ince
In order to do a long transcation the object has to be in the cache.
Is there anything I can do? In my case I am updating the object 60
seconds later.
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 5:40 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
there should be no need to reload the cached entities.
Regards
Ralf

Post by Stephen Ince
Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.
<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or
'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. [phone]
Mobil: [phone]
Fax [phone]

Internet: www.syscon.eu
E-Mail: ***@syscon.eu

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim

[Stephen Ince]

Ralf,
I figured it out. Things did work fine but I had an object outside the
ttl time of 60 seconds and I got timestamp exception. I just changed my
configuration to
<cache-type type="count-limited" capacity="200"/>. I now remove objects
from the cache when I do not need them.



Once the object is gone from the cache, I take it there is no way to do a
long transaction update.

Steve

----- Original Message -----
From: "Ralf Joachim" <***@syscon.eu>
To: <***@castor.codehaus.org>
Sent: Wednesday, October 01, 2008 10:15 AM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Sorry, I do not understand. Can you please explain what you want to
know. According to the last mail I thought things work now.
Ralf

Post by Stephen Ince
In order to do a long transcation the object has to be in the cache.
Is there anything I can do? In my case I am updating the object 60
seconds later.
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 5:40 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
there should be no need to reload the cached entities.
Regards
Ralf

Post by Stephen Ince
Ralf,
Thx for your reply and help. I got it to work by using 60 ttl.
<cache-type type="time-limited" capacity="60"/>.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly);
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Is it necessary for me to reload the object in the cache?
db.begin();
System.err.println("updating("+u+")=" + u.jdoGetTimeStamp());
db.update(u);
db.commit();
Steve
----- Original Message ----- From: "Ralf Joachim"
Sent: Tuesday, September 30, 2008 12:32 PM
Subject: Re: [castor-dev] ObjectModifiedException error

Post by Ralf Joachim
Hi Stephen,
till 1.3 release of Castor there are 2 requirements for entities that
are used at long transactions.
- the entity have to implement the TimeStampable interface
- the entity has to stay in cache from being loaded until update is
called with it
According to your test scenarios the second seams not to be the case
(case 2).
Backgroud of the ObjectModifiedException in cases 1 and 3 is, that an
entity always gets a new timestamp value when it is loaded from
database. As the entity you explicitly loaded into cache in cases 1 and
3 got a different timestamp the ObjectModifiedException gets thrown at
update.
To prevent this you have to use cache type 'unlimited' or
'time-limited'
with a ttl that is bigger than the time between you initial load and the
call to update. Having said that this also does not help if the entity
is part of an extends hierarchy. There is a open issue (castor-1217)
about that.
If keeping entities in cache for such a long time is not an option to
you, maybe according to the number of entities involved, or the entity
is part of an extends hierarchy, there are only 2 options.
- copy changed properties of the entity by hand into an entity loaded in
the transaction
- switch to the upcoming 1.3 release which allows to persist the
timestamp in database
If you like to know more about persisting timestamp let me know and I'll
point you into the right direction. To reduced turnaround you may want
to connect to castor channel at: http://irc.codehaus.org/
Regards
Ralf

Timestamp mismatched!" error when saving a long transactions. How can
I avoid this. I have tried the following.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.update(u);
db.commit();
db.begin();
db.update(u);
db.commit();
I get object not in cache error for this case.
db.begin();
db.load(UserScenario.class,u.getUserScenarioId(),AccessMode.ReadOnly));
db.commit();
db.begin();
db.update(u);
db.commit();
Steve
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. [phone]
Mobil: [phone]
Fax [phone]
Internet: www.syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

Hi Werner,

at the moment I try to find a solution for CASTOR-1217. This would
requires a bigger refactoring of load process. Problem is that calling
LockEngine.load() twice for extended class hierarchies does not use
cache and always reloads these entities. I intend to commit a first
refactoring step of LockEngine and ClassMolder load that cleans up code
a bit before RC. These refactoring still does not resolve the issue.
Having said that I do not have an idea yet how much time it will take to
finally resolve the issue.

There is also a problem at db.create() that causes a
NullPointerException in SQLStatementLookup when a database constraint is
violated. As I had not been able to write a test case that reproduces
this problem, there is no jira issue about that yet. This issue seams to
be critical to me as it hides the original reason, a SQLException during
create.

Regards
Ralf

Post by Werner Guttmann
Hi,
most likely, I will manage to make a first release candidate of Castor
1.3 available tomorrow night (my local time). I have just created a new
1.3rc1 release in Jira, to allow us tracking of regression issues
(should any arise .. ;-)).
In addition, I'd like to get an idea what work you (committers) like to
ship with 1.3 final. Personally, I'd like to spend most of my time on
documentation only between RC1 and GA, and I think the same should apply
for everybody.
- Include the integration test case for the new JDO extensions for the
XML code generator (Werner).
- A few patches required to get the JAXB code moving again.
- New partial (pull) parsing module.
Regards
Werner
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. [phone]
Mobil: [phone]
Fax [phone]

Internet: www.syscon.eu
E-Mail: ***@syscon.eu

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Ralf,

what does this imply towards making RC1 available tomorrow. Do you want
me to wait one or more days, or are you have to see this integrated ...

a) for a RC2 (if required)
b) 1.3 GA
c) 1.3.1 ?

Just let me know your preferences.

Werner

Post by Ralf Joachim
Hi Werner,
at the moment I try to find a solution for CASTOR-1217. This would
requires a bigger refactoring of load process. Problem is that calling
LockEngine.load() twice for extended class hierarchies does not use
cache and always reloads these entities. I intend to commit a first
refactoring step of LockEngine and ClassMolder load that cleans up code
a bit before RC. These refactoring still does not resolve the issue.
Having said that I do not have an idea yet how much time it will take to
finally resolve the issue.

I hope that I will be able to dedicate some of my time to this issue
after I have made 1.3. RC1 available.

Post by Ralf Joachim
There is also a problem at db.create() that causes a
NullPointerException in SQLStatementLookup when a database constraint is
violated. As I had not been able to write a test case that reproduces
this problem, there is no jira issue about that yet. This issue seams to
be critical to me as it hides the original reason, a SQLException during
create.

How about (in a separate email) trying to describe the issue at hand in
more detail ? As much as you know ..... at least.

Post by Ralf Joachim
Regards
Ralf

Post by Werner Guttmann
Hi,
most likely, I will manage to make a first release candidate of Castor
1.3 available tomorrow night (my local time). I have just created a new
1.3rc1 release in Jira, to allow us tracking of regression issues
(should any arise .. ;-)).
In addition, I'd like to get an idea what work you (committers) like to
ship with 1.3 final. Personally, I'd like to spend most of my time on
documentation only between RC1 and GA, and I think the same should apply
for everybody.
- Include the integration test case for the new JDO extensions for the
XML code generator (Werner).
- A few patches required to get the JAXB code moving again.
- New partial (pull) parsing module.
Regards
Werner
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ralf Joachim]

See my comments inline.

Post by Werner Guttmann
Ralf,
what does this imply towards making RC1 available tomorrow. Do you want
me to wait one or more days, or are you have to see this integrated ...
a) for a RC2 (if required)
b) 1.3 GA
c) 1.3.1 ?
Just let me know your preferences.
Werner

Post by Ralf Joachim
Hi Werner,
at the moment I try to find a solution for CASTOR-1217. This would
requires a bigger refactoring of load process. Problem is that calling
LockEngine.load() twice for extended class hierarchies does not use
cache and always reloads these entities. I intend to commit a first
refactoring step of LockEngine and ClassMolder load that cleans up code
a bit before RC. These refactoring still does not resolve the issue.
Having said that I do not have an idea yet how much time it will take to
finally resolve the issue.

I hope that I will be able to dedicate some of my time to this issue
after I have made 1.3. RC1 available.

The changes needed for this have a huge impact on JDO. Personally I
would prefer this this to be available with a RC before a final release.
If I do not have a genius idea till tomorrow evening this will not be
fixed for RC1. Let's see how things go and discuss with an available
patch if we like to publish another RC or integrate it 1.3GA or 1.3.1.

Post by Werner Guttmann

Post by Ralf Joachim
There is also a problem at db.create() that causes a
NullPointerException in SQLStatementLookup when a database constraint is
violated. As I had not been able to write a test case that reproduces
this problem, there is no jira issue about that yet. This issue seams to
be critical to me as it hides the original reason, a SQLException during
create.

How about (in a separate email) trying to describe the issue at hand in
more detail ? As much as you know ..... at least.

I expect the changes to be small to fix this. As it is a bug I like to
integrate this for 1.3GA. First I have to create a test to reproduce
this and debug what goes wrong. Will focus on that after RC1 is available.

Post by Werner Guttmann

Post by Ralf Joachim
Regards
Ralf

Post by Werner Guttmann
Hi,
most likely, I will manage to make a first release candidate of Castor
1.3 available tomorrow night (my local time). I have just created a new
1.3rc1 release in Jira, to allow us tracking of regression issues
(should any arise .. ;-)).
In addition, I'd like to get an idea what work you (committers) like to
ship with 1.3 final. Personally, I'd like to spend most of my time on
documentation only between RC1 and GA, and I think the same should apply
for everybody.
- Include the integration test case for the new JDO extensions for the
XML code generator (Werner).
- A few patches required to get the JAXB code moving again.
- New partial (pull) parsing module.
Regards
Werner
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Fine by me.

Werner

Post by Ralf Joachim
See my comments inline.

Post by Werner Guttmann
Ralf,
what does this imply towards making RC1 available tomorrow. Do you want
me to wait one or more days, or are you have to see this integrated ...
a) for a RC2 (if required)
b) 1.3 GA
c) 1.3.1 ?
Just let me know your preferences.
Werner

Post by Ralf Joachim
Hi Werner,
at the moment I try to find a solution for CASTOR-1217. This would
requires a bigger refactoring of load process. Problem is that calling
LockEngine.load() twice for extended class hierarchies does not use
cache and always reloads these entities. I intend to commit a first
refactoring step of LockEngine and ClassMolder load that cleans up code
a bit before RC. These refactoring still does not resolve the issue.
Having said that I do not have an idea yet how much time it will take to
finally resolve the issue.

I hope that I will be able to dedicate some of my time to this issue
after I have made 1.3. RC1 available.

The changes needed for this have a huge impact on JDO. Personally I
would prefer this this to be available with a RC before a final release.
If I do not have a genius idea till tomorrow evening this will not be
fixed for RC1. Let's see how things go and discuss with an available
patch if we like to publish another RC or integrate it 1.3GA or 1.3.1.

Post by Werner Guttmann

Post by Ralf Joachim
There is also a problem at db.create() that causes a
NullPointerException in SQLStatementLookup when a database constraint is
violated. As I had not been able to write a test case that reproduces
this problem, there is no jira issue about that yet. This issue seams to
be critical to me as it hides the original reason, a SQLException during
create.

How about (in a separate email) trying to describe the issue at hand in
more detail ? As much as you know ..... at least.

I expect the changes to be small to fix this. As it is a bug I like to
integrate this for 1.3GA. First I have to create a test to reproduce
this and debug what goes wrong. Will focus on that after RC1 is available.

Post by Werner Guttmann

Post by Ralf Joachim
Regards
Ralf

Post by Werner Guttmann
Hi,
most likely, I will manage to make a first release candidate of Castor
1.3 available tomorrow night (my local time). I have just created a new
1.3rc1 release in Jira, to allow us tracking of regression issues
(should any arise .. ;-)).
In addition, I'd like to get an idea what work you (committers) like to
ship with 1.3 final. Personally, I'd like to spend most of my time on
documentation only between RC1 and GA, and I think the same should apply
for everybody.
- Include the integration test case for the new JDO extensions for the
XML code generator (Werner).
- A few patches required to get the JAXB code moving again.
- New partial (pull) parsing module.
Regards
Werner
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email