transaction handling

["Pill, Juergen" <Ju...@softwareag.com>]

I have encountered a possible inconsistency in transaction handling. A (very
first) PUT command is divided into 2 begin/commit transactions, the first
commits changes in the node store, the second changes in
RevisionDescriptor(s)Store and ContentStore. If the first commit would work
without problems, but the second commit encounters problems, the data in the
database would be inconsistent (see details at the end of this mail).

I would suggest following changes, which would overcome the above problem:

1) add the methods "abort()" and "isTransactionActive()" to the Service
interface (create a new interface?).
2) Remove the begin/commit calls in the classes ContentImpl and
StructureImpl
3) Call the begin/commit methods in the appropriate WebDav method
implementations, e.g.
org.apache.slide.webdav.method.PutMethod.executeRequest(). Add there a
finally clause which will call abort() in case of something strange
happened.
4) Handle the init process within a transaction.
5) Some more minor changes (e.g. extend the NamespaceAccessToken interface
by an additional method, so following call is possible in the
WebDav.executeRequest() methods:
" this.token.getNamespace().getUri(resourcePath).getStore().begin(); //
start the transaction"
(Is there a more elegant way of calling the transaction methods?)

Does this make sense and do you want us to apply these changes and post the
differences via mail.

Best regards and merry Christmas and a happy new year to all of you.

Juergen Pill

 




977492718314 - PUT on object /tamino/patient4.xml
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - Checking basic
permissions on new object
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - Basic permissions
granted for user 
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - TaminoNodeStore :
storeObject <uri>/tamino/patient4.xml
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - TaminoNodeStore :
storeObject <uri>/tamino
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -    <-- enumerateLocks
/tamino/patient4.xml  []
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -    <-- enumerateLocks
/tamino  []
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - ++++>
openTransaction: opened Transactions = 1
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -
-->TaminoRevisonDescriptorStore : retrieveRevisionDescriptors
/tamino/patient4.xml
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -    -->
createRevisionContent /tamino/patient4.xml  0 bytes
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -    -->
createRevisionDescriptor /tamino/patient4.xml
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO -    -->
storeRevisionDescriptors /tamino/patient4.xml
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0
Fri, 22 Dec 2000 14:45:18 GMT+01:00 - default - INFO - <++++
closeTransaction: opened Transactions = 0

Re: transaction handling

[Remy Maucherat <re...@betaversion.org>]

Quoting "Pill, Juergen" <Ju...@softwareag.com>:

> I have encountered a possible inconsistency in transaction handling. A
> (very
> first) PUT command is divided into 2 begin/commit transactions, the
> first
> commits changes in the node store, the second changes in
> RevisionDescriptor(s)Store and ContentStore. If the first commit would
> work
> without problems, but the second commit encounters problems, the data in
> the
> database would be inconsistent (see details at the end of this mail).
> 
> I would suggest following changes, which would overcome the above
> problem:
> 
> 1) add the methods "abort()" and "isTransactionActive()" to the Service
> interface (create a new interface?).

I was going to do something similar. Otherwise, the begin (and commit) method 
can get called multiple times on the same child store depending on how you 
stores are defined :(

> 2) Remove the begin/commit calls in the classes ContentImpl and
> StructureImpl
> 3) Call the begin/commit methods in the appropriate WebDav method
> implementations, e.g.
> org.apache.slide.webdav.method.PutMethod.executeRequest(). Add there a
> finally clause which will call abort() in case of something strange
> happened.

No, it doesn't have access to the store, so it can't do that.

> 4) Handle the init process within a transaction.

Ok.

> 5) Some more minor changes (e.g. extend the NamespaceAccessToken
> interface
> by an additional method, so following call is possible in the
> WebDav.executeRequest() methods:
> " this.token.getNamespace().getUri(resourcePath).getStore().begin(); //
> start the transaction"
> (Is there a more elegant way of calling the transaction methods?)

There's no way the Namespace object is going to be returned to the client app, 
as it would break the security model.
I'll try to come up with something, but I'm under the impression that trying to 
make the macro-ops (like the DAV ops) transactional would be a hack.

> Does this make sense and do you want us to apply these changes and post
> the
> differences via mail.
> 
> Best regards and merry Christmas and a happy new year to all of you.

I'll probably start doing all that after I come back from vacation.

Remy