Attempting to describe basic steps/changes I am trying to 1support
policies/intents and
2external connection passing in DAS. These two need to go together, as
trying
transaction(y/n) intent at present and for this to test, need ability to
support passing db
connection from component impl to DAS
Hi,
I have given this a try based on what I tried in JIRA-1665 (Sample Using
JOTM with DAS)
Here also I am using JOTM with SCA+DAS. Currently played with 2 simple
intents:
a transaction (Tx management from External TM), b noTransaction (Tx
management from DAS)
The only changes needed are as
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
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 is that the SCA spec group only has an
unpublished draft of the Transaction support spec. The intention is to
publish
:
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
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 is that the SCA spec group
forwarding last message to dev list...
On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Hi Amita, thanks for the examples, it always helps to clarify : ). My
comments:
Use Case 1:
I think if there is part of the code the user needs to control the
transaction directly, he would never
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
Amita,
Maybe I am not getting this. What is the user case scenario that you are
trying to cover with your suggestion (I understand what you are suggesting
to do, but not sure of use case)? In what case client needs what you are
mentioning, beyond what is provided today?
Thanks for the
Just looked more at the code and found something more interesting - :)
When there is no connectionInfo in DAS Config, managedtx defaults to true,
so when
connection is passed by user (as in TransactionTests), managedtx is true.
So, with the current code case 4) can not occur (which is actually
Here is my opinion:
1- There are 2 ways for user to provide a Connection to DAS, create one and
pass it to DAS on its creation or on ConnectionInfo. The first case is
already giving the access to the Connection to the user. On the second, I
think it's useful to provide access to it with
On 8/14/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Here is my opinion:
1- There are 2 ways for user to provide a Connection to DAS, create one
and
pass it to DAS on its creation or on ConnectionInfo. The first case is
already giving the access to the Connection to the user. On the
---if DAS exposes connection thru getConnection() ONLY when
managedtx=false, it need to control cases when managedtx=true. So 2. will be
needed.
If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx
loses its meaning and DAS can not control any transaction as client always
-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
Below is what is happening today:-
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
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
Hi Amita,
I think it can be useful to bunch commands, but I didn't get how you are
planning to do it : (
What would be the parameter of method getTransaction?
Regards,
Adriano Crestani
On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is a simple matrix based on current RDB DAS
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
Hi All,
I just want to clarify if the below is something missing in DAS or just that
I have not understood it clearly.
Appreciate your response.
At present, DAS has managedtx attribute at ConnectionInfo level(default
true). So when true
or not specificed, each Command does a database commit.
24 matches
Mail list logo
