Monday, September 02, 2002, 8:02:59 PM, you wrote:
BS> To make it more clear, consider the following operations as one transaction in
BS> a given thread:
BS> try {
BS> TA.start()
BS> operation on my tables
BS> Mkcol method--> which causes some operations on the slide's tables and is
BS> considered as one transaction in slide.
BS> operation on my tables
BS> TA.commit()
BS> } catch ( Exception e) {
BS> TA.rollback()
BS> }
BS> I know that we can not have nested transaction, so practically
BS> what I have written is wrong, but logically I want to have above
BS> order of transaction and I don't know how can I cancel the
BS> transaction commands in the Mkcol method. Is there any way??
Slide transactions are managed through the use of
NamespaceAccessToken's begin, commit and rollback methods. Still, you
can't write something like
try {
token.begin()
mymanager.begin()
mkcol()
myOwnOperations()
token.commit()
mymanager.commit()
} catch (Exception e) {
token.rollback()
mymanager.rollback()
}
because this still may cause inconsistencies in the database. On the
other hand, if you could manage to somehow use connection that one of
Slide store uses:
try {
token.begin()
mkcol()
myOwnOperations(token.getConnection())
token.commit()
} catch (Exception e) {
token.rollback()
}
it would be enough to guarantee consistent database updates.
The above code fragment is bogus because there's currently no way of
getting Connection from NAT. But if you patched one of the Slide stores
(the one which is used by all URIs) to put Connection in a thread
context object, you could later fetch this connection and pass it over
to myOwnOperations().
I'm not absolutely sure about this but I think the connection is first
fetched by a store after it performs its first operation. So you
should always perform you own operations *after* Slide.
--
Łukasz Kowalczyk
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
