Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <j2x16178eb11004201948o14622683n37a075b70e953143@mail.gmail.com>
References: <k2t3fd55ec81004181318wa08697c5h72b35638b7325abe@mail.gmail.com>
	 <i2r3fd55ec81004181331q76043fc1l6158e1b94712d001@mail.gmail.com>
	 <x2l16178eb11004181445ua11cb872x333e5199a90b8f5c@mail.gmail.com>
	 <z2l3fd55ec81004190026nb481d97ei568891c87405ea0b@mail.gmail.com>
	 <m2t16178eb11004190815qf91f1618z3e1f598a577c52ae@mail.gmail.com>
	 <4BCC93FB.8060802@burntmail.com>
	 <n2l3fd55ec81004191107s1f6d5fb4g59836a20867e2b6f@mail.gmail.com>
	 <4BCD093F.6090304@burntmail.com>
	 <j2x16178eb11004201948o14622683n37a075b70e953143@mail.gmail.com>
Date: Thu, 22 Apr 2010 14:32:12 -0700
Message-ID: <h2s3fd55ec81004221432z62a8c6c3k53ece730c4b85657@mail.gmail.com>
Subject: Re: Transaction management in iBATIS 3 inside an EJB (3.1) container
From: Adinath Raveendra Raj <adinath@acciente.com>
To: user-java@ibatis.apache.org
Content-Type: multipart/alternative; boundary=000e0cd177da304f370484da0be2

--000e0cd177da304f370484da0be2
Content-Type: text/plain; charset=ISO-8859-1

Clinton,

On Tue, Apr 20, 2010 at 7:48 PM, Clinton Begin <clinton.begin@gmail.com>wrote:

> Okay, I've looked around.  It is really hard to find the way it's
> "supposed" to work, but I don't think it matters.  There's more than enough
> empirical evidence (both in iBATIS 2 and Adinath's custom implementation).
> So I've added the close to the ManagedTransaction.  It will log but
> otherwise ignore exceptions thrown by close(), to deal with unexpected
> states (and re-throwing an exception from close could hide a more important
> root cause exception).
>

It is hard to find info on this, there is a WebSphere (from 2005) article (
http://www.ibm.com/developerworks/websphere/library/techarticles/0506_johnsen/0506_johnsen.html)
about  this topic that says:

*When the application closes a shareable connection, the connection is not
truly closed, nor is it returned to the Free pool. Rather, it remains in the
Shared connection pool, ready for another request within the same LTC for a
connection to the same resource.

** LTC = Local Transaction Containment

The funny thing is that I even had a unit test asserting this behavior, so I
> must have done it at some point for a reason. I just hope it wasn't a very
> good reason.  ;-)


Haha, been there :)


> It's also funny that it wasn't found in 10 betas... which either implies
> that not many people use  managed transactions, or that some app servers
> behave as I thought they would.
>
> I'm going to recommend a re-build before we take iBATIS 3 to GA, so the
> iBATIS release we'll vote on will probably be 3.0.1.
>

Thanks, I think your changes are going to help others avoid this issue. Keep
up the excellent work.

Best,
Adi

-- 
Acciente, LLC
Systems Architecture and Software Design

www.acciente.com
www.inductionframework.org

--000e0cd177da304f370484da0be2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Clinton, <br><br>On Tue, Apr 20, 2010 at 7:48 PM, Clinton Begin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:clinton.begin@gmail.com">clinton.begin@gmail=
.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
Okay, I&#39;ve looked around.=A0 It is really hard to find the way it&#39;s=
 &quot;supposed&quot; to work, but I don&#39;t think it matters.=A0 There&#=
39;s more than enough empirical evidence (both in iBATIS 2 and Adinath&#39;=
s custom implementation).=A0 So I&#39;ve added the close to the ManagedTran=
saction.=A0 It will log but otherwise ignore exceptions thrown by close(), =
to deal with unexpected states (and re-throwing an exception from close cou=
ld hide a more important root cause exception). <br>
</blockquote><div><br>It is hard to find info on this, there is a WebSphere=
 (from 2005) article (<a href=3D"http://www.ibm.com/developerworks/webspher=
e/library/techarticles/0506_johnsen/0506_johnsen.html">http://www.ibm.com/d=
eveloperworks/websphere/library/techarticles/0506_johnsen/0506_johnsen.html=
</a>) about=A0 this topic that says:<br>
<br><b>When the application closes a shareable connection, the connection i=
s
 not truly closed, nor is it returned to the Free pool.  Rather, it=20
remains in the Shared connection pool, ready for another request within=20
the same LTC for a connection to the same resource.<br><br></b>* LTC =3D Lo=
cal Transaction Containment<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;">


The funny thing is that I even had a unit test asserting this behavior, so =
I must have done it at some point for a reason. I just hope it wasn&#39;t a=
 very good reason.=A0 ;-)=A0=A0 </blockquote><div><br>Haha, been there :)<b=
r>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">It&#=
39;s also funny that it wasn&#39;t found in 10 betas... which either implie=
s that not many people use=A0 managed transactions, or that some app server=
s behave as I thought they would.=A0 <br>


<br>I&#39;m going to recommend a re-build before we take iBATIS 3 to GA, so=
 the iBATIS release we&#39;ll vote on will probably be 3.0.1.<br></blockquo=
te><div><br>Thanks, I think your changes are going to help others avoid thi=
s issue. Keep up the excellent work.<br>
<br>Best,<br>Adi<br></div></div><br>-- <br>Acciente, LLC <br>Systems Archit=
ecture and Software Design <br><br><a href=3D"http://www.acciente.com">www.=
acciente.com</a><br><a href=3D"http://www.inductionframework.org">www.induc=
tionframework.org</a><br>


--000e0cd177da304f370484da0be2--