I tried it again, but the sample stored procedure that you sent me
does not blow until commit phase, so the exception is different and
the behavior is different.
Now the auto-commit... yeah, I traced down the reset of auto-commit
flag. It happens in Cayenne code right after "willAddConnection". One
possible fix... Instead of creating a manual transaction like this
(per docs advice) :
DataDomain domain =
Configuration.getSharedConfiguration().getDomain();
Transaction tx = domain.createTransaction();
Do this:
Transaction tx = Transaction.externalTransaction(delegate);
An "external" transaction will not override connection auto-commit
flag, so your delegate setting should take effect. Somehow I forgot
about this option.
Andrus
On Apr 29, 2008, at 3:27 PM, Marc Gabriel-Willem wrote:
Dear Andrus,
Yes this is very disappointing since manual transaction with no
autocommit does not work for us.
Perhaps we need to clarify this?
At this point, the only working way is to use directly JDBC with
autocommit (which is not an option for us).
Neither the use of manual transaction with no autocommit nor the use
of
TransactionDelegate with autocommit makes our problem solved.
And for your information, we have performed our tests with Cayenne
2.0.4
and 3.0M3 as well and unfortunately it doesn't make any difference.
We hope this summary clarify the actual state of this issue.
Many thanks for your kind assistance,
Best regards,
Marc
-----Original Message-----
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 11:10 AM
To: user@cayenne.apache.org
Subject: Re: Stored proc returning result set (and output params) with
MS SQL server
I am surprised about autocommit making a difference vs. a manual
transaction with no autocommit, as the later worked for me in my
previous test, so now everything I say is just a guess. One other
difference that I noticed is that I tested using Cayenne 3.0 trunk
(soon to be M4), and you are on 2.0.4. I'll need to try it with 2.0 in
my next test...
Andrus
On Apr 29, 2008, at 12:00 PM, Marc Gabriel-Willem wrote:
Hello Andrus,
We've set the autocommit to true using a TransactionDelegate but
somehow, it appears the flag is later on reset automatically to
false.
As you advised, the autocommit has been set to true in
willAddConnection, but when didRollback or didCommit is called, we
figured out the flag has been reset to false. So it seems the
setAutoCommit is not taken into account, and then of course our issue
still persists.
Please can you advise?
Thanks a lot
Marc
-----Original Message-----
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 2:48 PM
To: user@cayenne.apache.org
Subject: Re: Stored proc returning result set (and output params)
with
MS SQL server
On Apr 28, 2008, at 3:41 PM, Marc Gabriel-Willem wrote:
Dear Andrus,
Have you got a chance to work on the problem?
No, not yet.
For a summary, our investigations show that using JDBC, the 'auto
commit' attribute set to 'true' solve the problem. Is it possible to
execute the stored procedure using that behavior? We already looked
to
set that flag to a particular connection within cayenne, but without
any
success...
You may try using a TransactionDelegate that sets autocommit to true
based on some ThreadLocal variable state from within
'willAddConnection':
http://cayenne.apache.org/doc/understanding-transactions.html
Andrus
------------------------------------------------------------------
CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s)
only. Any review, retransmission, dissemination or other use of, or
taking any action in reliance upon this information by persons or
entities other than the intended recipient(s) is prohibited. If you
have received this e-mail in error please notify the sender
immediately and destroy the material whether stored on a computer or
otherwise.
DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those of
SIDE International S.A. - EastNets Group, unless otherwise
specifically stated.
------------------------------------------------------------------
Please consider the environment before deciding to print this email.
