Hello,
I am running a query on Hasta Schema
then change a fields value and submit the document back to Tamino
Not always but sometimes I get this exception while trying to commit and this crashes Database !!!
I need to restart the database after this.
Why does this happen?
Thanks Server…

Here is the code that causes exception

…
QueryContainer query = new QueryContainer(“Hasta”);
query.add(new QueryElement(“Kimlik/DogumYeri”, src, “=”));
query.add(new QueryElement(“@ino:id”, “3500”, “<”));
Cursor docCursor = ws.query(“qrySehir”+i, query);
int counter=0;
while (docCursor.hasNext()) {
BusinessDocument doc = (BusinessDocument)docCursor.next();
doc.read();
doc.modify();
doc.getRoot().getDescendant(“/Hasta/Kimlik/DogumYeri”).setValue(target);
System.out.println(counter++ + " : " + src + " → " + doc.getRoot().getDescendant(“/Hasta/Kimlik/DogumYeri”).getValue() + " ino :" + doc.getDocumentId());
doc.commit();
}
docCursor.close();
…

Here is the Exception

0 : Ä°STANBUL → Ä°STANBUL ino :/Hasta[@ino:id=‘3271’]

StoreException: id = 161 arg[0] = could not change to autocommit mode after rollback exception

Local transaction mode could not be released properly. Falling back to autocommit mode.
NestedException:NestedException:Retry after invoke failed.
NestedException:HTTP failure.
NestedException:HTTP invocation failure.

at com.softwareag.tamino.db.API.connection.TTransactionModeCoordinatorImpl.releaseLocalTransactionMode(TTransactionModeCoordinatorImpl.java:359)

at com.softwareag.tamino.db.API.connection.TTransactionModeCoordinatorImpl.useAutoCommitMode(TTransactionModeCoordinatorImpl.java:64)

at com.softwareag.tamino.db.API.connection.TConnectionImpl.useAutoCommitMode(TConnectionImpl.java:195)

at com.softwareag.xtools.xapplication.store.TaminoStore.rollbackTransaction(TaminoStore.java:476)

at com.softwareag.xtools.xapplication.store.TaminoStore.update(TaminoStore.java:1110)

at com.softwareag.xtools.xapplication.businessdocument.SingleBusinessDocument.updateDocument(SingleBusinessDocument.java:913)

at com.softwareag.xtools.xapplication.businessdocument.state.Modifiable.commit(Modifiable.java:73)

at com.softwareag.xtools.xapplication.businessdocument.SingleBusinessDocument.commit(SingleBusinessDocument.java:279)

at hitit.go.changer(go.java:101)

at hitit.go.main(go.java:71)

Process exited with exit code 0.

X-Application Version: 3.1.3, 3.1.2, 3.1.1
Tamino Version : 3.1.1
Platform : NT, Win2k, Solaris, …
WebContainer : Tomcat 3.3
JDK Version : 1.3.1

[This message was edited by Christian Freytag on 05 Sep 2002 at 13:31.]

Hello,

I checked the Stacktrace of the exception. According to this stacktrace, the database has to be restarted if X-Application’s TaminoStore makes rollback for an update.

That the database has to be restarted is not normal. Therefore, I forwarded your request to the Tamino support.

The reason for the rollback is the update interval for the document: The stacktrace indicates that the document is updated, read and updated again within one second.

E.g. User A updates the document at time
12:33:59:1020

User B read the document at time
12:33:59:1230

and updates the document at time
12:33:59:1430

User B is very quick making his changes since he needs only 200 milli seconds.

The timestamp for a document has a time resolution of 1 second. Therefore X-Application’s TaminoStore does not allow this update. It throws an UpdaeAssertionFailed Exception and rolls back the transaction.

For user interaction the time resolution of 1 second is ok, because a user normally needs more than a second to update his document.

If you have written an application the time resolution is to not sufficient.

To avoid the UpdateAssertionFailed Exception within the TaminoStore you could

(A) wait for at least 1 second before updating a document after reading it.

(B) modify the class TaminoStore.java at line 1099. Just delete the check for the timestamp equality.

Disadvantage of B: you cannot detect changes by other Users which are made between you read and update cycle if the timeframe for the updates is lesser than 1 second.

Bye,
Christian.

Hello Christian,
Why is my message indicating my problem replaced with your answer???
Please look at my first message above…

I did not understand the problem excatly.
First there are not two users in my scenario but only one.
Second I dont commit the same document two times but each time a different document…

Thanks
Server

Hello,

the same think, if you have only one user or one process

If process P reads the document and updates it at
12:33:59:1010

reads the document again at
12:33:59:1210

and updates it at
12:33:59:1410

the UpdateAssertionFailed is thrown by the X-Application’s TaminoStore.

Bye,
Christian.

PS: Excuse me - I overwrote your message but I restored it.

Hello,
I am not reading the same document but another one.
Doesn’t this change the situation?
Server

Hello,

the UpdateAssertionFailed Exception is only thrown by the scenario I mentioned before. But, it could be than your process read 10 or more documents before reading and updating the same document D. E.g.:

12:33:59:010 → update document D -----

12:33:59:120 → read document d1
12:33:59:220 → read document d2
12:33:59:320 → read document d3
12:33:59:420 → read document d4
12:33:59:520 → update document d1
12:33:59:620 → update document d2

12:33:59:720 → read document D
12:33:59:730 → update document D ----- → exception

I am not sure if it’s public, but the SingleBusinessDocument class contains a Timestamp object. If you have only one process and trace ino:id and the timestamp, you should find out the former update of the document whose update causes the UpdateAssertionFailed Exception.

Bye,
Christian.

hello mehmet,

in order to determine the cause for the server crash, it would help greatly if you could provide a log of the communication that takes place between your application and the database.

in case you were wondering you to get that: please browse to

http://www.schmerg.com

and download the HttpSniffer.
please provide the generated log (one that contains a crash).

regards,

andreas f.