Thanks Conor and Robin,
I have already try different configuration of the cache-type and no solution
here for me.
But, I think I found the solution, it was in one portion of the developper's
code.
I eplain:
The error was on some contents but not on the others (those which are
delivered with my app :) ).
In these contents, the editionForm has many combo-box which listed another
contents.
One combo-box calls a UserFactory and try to get all objects to fill in the
combo-box.
I cannot explain why but if I replace :
-> UserFactory uf = new UserFactory(application);
-> Vector users = uf.getAll();
by:
-> UserFactory uf = new UserFactory(application);
-> Vector users = new Vector();
to empty the combo box.
Then I have no "Timestamp mismatched" error updating the same contents !!!!
I don't believe that !? If someone have a rational explaination to this, I
offer ... my gratitude :)
The uf.getAll forward to the PersistenceEngine.findAll() which is in
"PersistenceEngine.CastorReadOnlyMode".
Perhaps this join problems encountered by other ones whith "Long Transaction
and read-only access" ?
In attach file a post from someone which encountered such problems,
I will now test his solution to see if my problem is solved.
Thanks everyone,
REMICOURT Beno�t
-----Message d'origine-----
De : Robin Hoogeboom [mailto:[EMAIL PROTECTED]]
Envoy� : mardi 21 janvier 2003 12:22
� : [EMAIL PROTECTED]
Objet : Re: [castor-dev] Need Quick Help -- Timestamp mismatched
Hi,
Nope, your right Conor.
a solution would be to set the cache-timeout to a higher time level in
your mapping file (or another style)
ex.
<cache-type type="time-limited" capacity="3"/>
or to set your specific field to dirty="ignore" in your mapping file.
No change/timestamp checking is done and you can save without
an exception
Good luck.
Robin
----- Origineel Bericht -----
Van: "Conor Allen" <[EMAIL PROTECTED]>
Datum: Dinsdag, Januari 21, 2003 12:03 pm
Onderwerp: Re: [castor-dev] Need Quick Help -- Timestamp mismatched
> I believe that for long transactions to work that the cache must
> have a version of the object to compare against (for timestamp
> checking and to generate the dirty checking update). That means
> that if the server process is restarted that the long transaction
> will fail. Also, if the object is dropped out of the cache (if you
> are using count or time limited cache algorithms) the same thing
> will probably happen.
>
> Am I wrong?
>
> Conor
>
> -----Original Message-----
> From: REMICOURT Beno�t [mailto:[EMAIL PROTECTED]]
> Sent: 21 January 2003 10:49
> To: [EMAIL PROTECTED]
> Subject: [castor-dev] Need Quick Help -- Timestamp mismatched
> Importance: High
>
> Hi everyone,
>
> I encounter a big and very blocking error on my application using
> Castor0.9.3.21.
> I have already deploy the same application for different clients
> before with
> no problems till now.
>
> The config is that time:
> - Linux Red Hat
> - Postgres 7.1
> - Tomcat 3.3.1
> - Castor 0.9.3.21
> - My App
> - Specific project classes linked with my app
>
> My problem is, I am the developper of the core of the project (My
> App), a
> Web Content Management Tool to build Dynamic WebSites with lots of
> editorialcontents.
> Contents are created/edited/updated/deleted with back office
> interface and
> viewed with front office (= website).
>
> I am using long transactions.
>
> Problem is in back office when I tried to udpdate a content, a
> "Timestampmismatched" error occured.
> I try to find out what is the problem because for this project I
> was not the
> "specific classes" developper.
> After reviewing all the code of the developper, it seems to be
> correct and
> conform with my app.
>
> I, so, try to debug and find where the problem appears:
>
> In
> "org.exolab.castor.persist.ClassMolder.update(TransactionContext, OID,
> DepositBox, Object, AccessMode)" castor try that:
>
> -> fields = (Object[]) locker.getObject( tx );
> ->
> -> if ( !isDependent() && !_timeStampable )
> -> throw new IllegalArgumentException("A master object that
> involves in a long transaction must be a TimeStampable!");
> ->
> -> long lockTimestamp = locker.getTimeStamp();
> -> long objectTimestamp = _timeStampable?
> ((TimeStampable)object).jdoGetTimeStamp(): 1;
> ->
> -> if ( objectTimestamp > 0 && oid.getIdentity() != null ) {
> -> ...
>
> And in fact, locker.getObject( tx) returns NULL ! No object in
> cache !
> So locker's timestamp is 0 and object timestamp is different =>
> Timestampexception !
>
> The problem is, ok the cache is empty for this object but how can
> I refresh
> the whole cache ?
> Or how to make castor to not check the cache and force update my
> object ?
>
> If anyone have a solution to this problem, please help.
> I have to solve this before the end of the week, so if anyone can
> help me,
> thanks in advance.
>
> Sincerely, thanks all for your job with Castor,
>
> REMICOURT Beno�t
>
>
> Tout usage de ce message par une personne autre que son
> destinataire est
> strictement interdit. L'int�grit� de ce message n'�tant pas
> assur�e sur
> Internet, Le Groupe EUROGICIEL ne peut �tre tenu responsable de
> son contenu.
> Toute utilisation ou diffusion non autoris�e est interdite. Si
> vous n'�tes
> pas destinataire de ce message, merci de le d�truire et d'avertir
> l'exp�diteur.
>
> The information above is for the sole use of the individual or
> entity to
> which it is intended. If you are not the intended recipient of
> this message,
> you are hereby notified that any dissemination, distribution or
> copying of
> this document is strictly prohibited. The integrity of this
> message cannot
> be guaranteed on the Internet. EUROGICIEL Group shall in no way be
> liablefor its content. Please destroy this message and notify the
> sender.
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
>
> --
>
> This e-mail is confidential and is intended for the named
> recipient only. If
> you receive it in error please destroy the message and all copies.
> KainosSoftware Ltd. does not accept liability for damage sustained
> as a result of
> malicious software (e.g. viruses). Kainos does not accept
> liability for, or
> permit, the creation of contracts on its behalf by e-mail, the
> publication of
> any defamatory statement by its employees by e-mail, or changes
> subsequentlymade to the original message. The Company's registered
> office is located at
> 4-6 Upper Crescent, Belfast, BT7 1NT, Northern Ireland, Tel +44 28
> 9057 1100.
>
> -----------------------------------------------------------
> 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
Tout usage de ce message par une personne autre que son destinataire est
strictement interdit. L'int�grit� de ce message n'�tant pas assur�e sur
Internet, Le Groupe EUROGICIEL ne peut �tre tenu responsable de son contenu.
Toute utilisation ou diffusion non autoris�e est interdite. Si vous n'�tes
pas destinataire de ce message, merci de le d�truire et d'avertir
l'exp�diteur.
The information above is for the sole use of the individual or entity to
which it is intended. If you are not the intended recipient of this message,
you are hereby notified that any dissemination, distribution or copying of
this document is strictly prohibited. The integrity of this message cannot
be guaranteed on the Internet. EUROGICIEL Group shall in no way be liable
for its content. Please destroy this message and notify the sender.
--- Begin Message ---
Hello there !
I spent hours on my problems on using long transactions in casto 0.9.4.1
I think a lot of users which uses long transactions have been driven mad by
this and the listed exceptions below should be them well known.
So I studied the code in order to find out what are really the limits and
the matters. I found a solution for me to use "read-only" access to minimize
the limits, but I still needed to add some few lines tothe original castor
code in order to get it run.I think the most of my adapted code is a bug
fix of castor.
This mail should help to understand these Exceptions and my workaround.
Other users or developers should verify it and if they have a better
solution please feel free to give me any feedback on this.
- Exception: update object which is already in the transaction
- Exception: Duplicate identity found for object of type .... with identity
0: an object with the same identity already exists in persistent storage
- Exception: The identity of a data object of type ... has been changed
...l since it is loaded/create/update
- Exception: Timestamp Mismatch
All these Exceptions occure on updating or creating an object.
The basic workaround to get out of all the troubles during long transactions
is to use "read-only" objects. So during your developed update workflow, use
as much as possible read only objects. Example if you have a simple object
model of employees which are part of departments so the departments values
are fix (constants) have not be updatet during an update of an employee. To
affect this you believe in using "read-only" access for rthe department
objects. Unfortunately Castor has bugs here.
Exception: update object which is already in the transaction:
-----------------------------------------------------------
The first one is an ugly one and is described very well in
http://castor.exolab.org/list-archive/msg07928.html As we know castor uses
internal a cache for each transaction in order to handle the commit and
rollback. Unfortunately there are limits so there can only one object exist
in a transaction which has this identity. Otherwise you get this error if
you try to update. But when does this really occure ? Castor contains a
piece of documentation in his source code:
Load an object for use within the transaction. Multiple access
to the same object within the transaction will return the same
object instance (except for read-only access)
This means that it could only occure if you are loading read only objects,
which have you defined in the class element in your jdo mapping xml file.
Right ? Why should castor then update a "read-only" object ? Yes, it seems
to be bug. So I found the code position and it seems that the programmer do
not verify if the object is "read-only" during an update or creation. You
have to go to the class 'org.exolab.castor.persist.TransactionContext' to
the method 'markUpdate'. There will each object added to an interal cache of
this class which have to be updated. If the 2 same objects will be added to
this cache you get this exception described above. The adding is done by the
method:
'addObjectEntry'. In order to consider that read-only objects have to be
skipped you have to verify the access mode as like this:
AccessMode accessMode = molder.getAccessMode(null);
if(accessMode != AccessMode.ReadOnly)
{
entry = addObjectEntry( oid, object );
....
}
else return false;
This solves your first Exception.
Exception: Duplicate identity found for object of type .... or
Exception: The identity of a data object of type ... has been changed ...l
since it is loaded/create/update
--------------------------------------------------------
This Exception happens if you try to insert a new object with the same id
into the database, where this id is already used. The object exists already
in the database. Castor has the bug also to try write "read-only" objects
back to the database. So if you have an employee with several chil
departments objects. It tries to write the department objects. If you have
defined a key generator for the departments then you will get the strange
exception: "The identity of a data object of type ... has been changed ...l
since it is loaded/create/update" otherwise you get the error
"Duplicate identity found for object of type .... with identity 0: an
object with the same identity already exists in persistent storage". To
remove this behaviour you have to go to the same class and
'org.exolab.castor.persist.TransactionContext' to the method: markCreate.
This method will be called for each field of the object which have to be
updated. If this field is an object, so markCreate will on this be called.
Castor does currently not matter if this Object is "read-only" or not. The
correction is here the same as above we have to verify the access mode
if (molder.getAccessMode(null) != AccessMode.ReadOnly) ...
This will solve this Exception and your read only objects will not be
written to the database any more.
Exception: Timestamp Mismatch
---------------------------------
This errors occuring if the timestamp of the lock engine is not the same
with the object which we will to update. This happens only if the lock
engine has no time stamp produced. And this happens if the cache
configuration does not allow to cache the object. For example
<cache-type type="none"/> or <cache-type type="count-limited" capacity="1"/>
in your jdo mapping will end in this exception. So be carefull if you mean
you can use long transactions without the caching algorithm.
So the workarounds above helped me to go further in my project. But use it
at your own risk. I hope one of the deloper of castor have a look at it and
can give any feedback if this is correct and fine, or what is a better
workaround.
Good Luck!
regards
Mark
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
--- End Message ---
