Re: Using Slide transaction's connection

["B. Shadgar" <sh...@compsci.bristol.ac.uk>]

Tom Wang wrote:

> Bita,
>
> I don't have sample code to show you but I'll try to explain better.  Take a
> look at J2EEDescriptorsStore.  It maintains a connection map to support
> concurrent clients.  This way the store knows which connection to use when
> dealing with a specific thread.  What I was suggesting is to save the
> connection reference in the current thread context (you'll need to create
> the context yourself, maybe using ThreadLocal).  Since at the app layer you
> only have the handle to NamespaceAccessToken, which means you can't get to
> the connection map since it's hidden by the store impl.  But you can get the
> connection from your current thread context.  Am i making sense?
>
> Tom Wang
> Panscopic Corporation
> Web Reporting, Just Add Data
> http://www.panscopic.com/download

Tom & Lukasz

Now I understand your mean quite better. But still I am not clear when there
were some other tables in the same database as slide's tables, and we are going
to consider a bunch of  operations,  whether on the Slide's tables or other
tables, as one transaction. In this case I don't know how the thread context
can help me, or even does it help or not?

To make it more clear, consider the following operations as one transaction in
a given thread:
try {
   TA.start()
   operation on my tables
  Mkcol method--> which causes some operations on the slide's tables  and is
considered as one transaction in slide.
  operation on my tables
  TA.commit()
} catch ( Exception e) {
  TA.rollback()
}

I know that we can not have nested transaction, so practically what I have
written is wrong, but logically I want to have above order of transaction and I
don't know how can I cancel the transaction commands in the Mkcol method.
Is there any way??

Regards,
Bita.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re[2]: Using Slide transaction's connection

[Lukasz Kowalczyk <lu...@jazzpolice.pl>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>