Hey, very good, some comments inline
One question that I have is regarding the Transaction Manager, who is
responsible for creating the transaction manager ? The SCA runtime, or
implementations ? In the case of SCA runtime, we need to investigate
that part, but I guess we can start by having it
[snip]
Luciano Resende wrote:
I guess your suggestion for starting simple is fine, and I guess
implementation.das could get integrated with SCA Policy and DAS would
have the necessary support, unless we find some bugs on the DAS side.
I'll see if I can get to this in the coming weeks...
BTW,
Hi,
I have tried to use JOTM and Tomcat and would like to create a sample web
app in
DAS showing how external transaction manager can control DAS transactions.
I am creating another mail thread for any discussion for this sample + JOTM
issues.
We can demonstrate through this and accompanying wiki
:
Folks,
Sorry to cut across the discussion about Transaction support in DAS, but
are folks aware of the proposal for Transaction support in SCA?
which leads to the entertaining question of how the DAS transaction
support relates to the SCA transaction support.
The problem at the moment
Folks,
Sorry to cut across the discussion about Transaction support in DAS, but
are folks aware of the proposal for Transaction support in SCA?
which leads to the entertaining question of how the DAS transaction
support relates to the SCA transaction support.
The problem at the moment
Just trying to see what changes will be needed (marked with )
1) when connection from user, and he wants to delegate transaction control
to DAS,
allow it only per/Command. This will save user from issuing one
commit/rollback per command in the client code. (i.e. current way of
By doing a quick debug on Amita's testcase from JIRA-1543, looks like
we might have some bugs in our current code, that might be causing
this whole confusion. Let me spend couple hours on this over the
weekend, and send some feedback after that. I'll also write a wiki
page with what I think the
Hi Haleh,
Please see all the use case details below.
There are three user cases going wrong which I am trying to fix.
I have created a JIRA-1543 to demonstrate with examples how DAS is failing
in these use case scenarios. Patch contains 3 new test cases as below in
TransactionTests.java.
So far
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection()
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and
Comments inline
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is what is happening today:-
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
Below is a simple matrix based on current RDB DAS Config, showing what it
does/does not
do today
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
12 matches
Mail list logo
