Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 51735 invoked from network); 10 Nov 2009 15:26:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Nov 2009 15:26:47 -0000 Received: (qmail 4408 invoked by uid 500); 10 Nov 2009 15:26:46 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 4389 invoked by uid 500); 10 Nov 2009 15:26:46 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 4381 invoked by uid 99); 10 Nov 2009 15:26:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Nov 2009 15:26:46 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of clinton.begin@gmail.com designates 74.125.92.148 as permitted sender) Received: from [74.125.92.148] (HELO qw-out-1920.google.com) (74.125.92.148) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Nov 2009 15:26:44 +0000 Received: by qw-out-1920.google.com with SMTP id 14so17785qwa.60 for ; Tue, 10 Nov 2009 07:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ohRdnUSSe5FOVPANh2aIudRfeV3qkLLEVEehmZkdkz0=; b=C1ZJmX68c4QARKnPsl4XdNgn9rIOHk/vnFBme01NJ4z+k7AkJ6xudrCQ+BEXB++LDc 4mjo5Ip1r/efZRxIWrPR4wDwlQHMJX7NDG4TEyEQQnQHxNcfiGL9Ukd1/xro9PVjGnls WMtw4CuRRB4eYoLYmcozrEN3lbHY5y/6CQbCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XzCPtpBmK96lZe8QnVMIEI4AmYQNPDFVkMtL3QnZi8SdKdh54uSzFUNY+ykKqlm5Es Sh+Lpn821F8BuBkY4vHGOWlaErRtf1mne4+yebKotYfSZptSI52RnC8bAavqwikKFwia NNtDZrukUU3pv+PEaDjDQnHYxGkP7DwYoAb5A= MIME-Version: 1.0 Received: by 10.224.43.160 with SMTP id w32mr96873qae.277.1257866783002; Tue, 10 Nov 2009 07:26:23 -0800 (PST) In-Reply-To: <93B0CB1886D4CC48823246865D80DC940453A399FE5A@HERMES.ircm.priv> References: <93B0CB1886D4CC48823246865D80DC940453A399FE5A@HERMES.ircm.priv> Date: Tue, 10 Nov 2009 08:26:22 -0700 Message-ID: <16178eb10911100726m5c297016u7f5d56b088cab800@mail.gmail.com> Subject: Re: Potential connection problem when using managed transactions in iBATIS 3 From: Clinton Begin To: user-java@ibatis.apache.org Content-Type: multipart/alternative; boundary=00c09f972a55c69243047805ee53 --00c09f972a55c69243047805ee53 Content-Type: text/plain; charset=ISO-8859-1 That is a little odd. It looks like I intended for something else there. I'll look at it. Clinton On Tue, Nov 10, 2009 at 8:09 AM, Poitras Christian < Christian.Poitras@ircm.qc.ca> wrote: > What is the expected behaviour when calling dataSouce.getConnection() for > managed transactions in iBATIS 3? > > I find suspicious that ResultLoader calls dataSouce.getConnection() at line > 89 which could create an unexpected connection. And since managed > transaction is used, the connection may never be closed. > > > Christian > > > Here is the code from ResultLoader which calls dataSouce.getConnection() : > > *private* Executor newExecutor() *throws* SQLException { > > Environment environment = > configuration.getEnvironment(); > > *if* (environment == *null*) > > *throw* *new* ExecutorException("ResultLoader could not load lazily. > Environment was not configured."); > > TransactionFactory txFactory = environment.getTransactionFactory(); > > *if* (txFactory == *null*) > > *throw* *new* ExecutorException("ResultLoader could not load lazily. > Transaction Factory was not configured."); > > DataSource ds = environment.getDataSource(); > > *if* (ds == *null*) *throw* *new* ExecutorException("ResultLoader could > not load lazily. DataSource was not configured."); > > Connection conn = ds.getConnection(); > > conn = wrapConnection(conn); > > Transaction tx = txFactory.newTransaction(conn, > *false*); > > *return* configuration.newExecutor(tx, ExecutorType.*SIMPLE*); > > } > --00c09f972a55c69243047805ee53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is a little odd.=A0 It looks like I intended for something else there.= =A0 I'll look at it.

Clinton

O= n Tue, Nov 10, 2009 at 8:09 AM, Poitras Christian <Christian.Poitras@ircm.qc.ca> wrote:
What is the expected=20 behaviour when calling dataSouce.getConnection() for managed transactions i= n=20 iBATIS 3?
=A0
I find suspicious=20 that ResultLoader calls dataSouce.getConnection() at line 89 which=A0could= =20 create an unexpected=A0connection.=A0And since managed transaction is=20 used, the connection may never be=A0closed.
=A0
=A0
Christian
=A0
=A0
Here is the code=20 from ResultLoader which calls dataSouce.getConnection() :

private Execu= tor newExecutor()=20 throws SQLException {

Environment environment =3D

configuration.getEnvironment();

if (environme= nt =3D=3D null)

throw = ne= w=20 ExecutorException("ResultLoader could not load lazily. Environment w= as not=20 configured.");

TransactionFactory txFactory =3D=20 environment.getTransactionFactory();

if (txFactory= =3D=3D null)

throw = ne= w=20 ExecutorException("ResultLoader could not load lazily. Transaction F= actory was not=20 configured.");

DataSource ds =3D environment.getDataSource();

if (ds =3D=3D= null)=20 throw new=20 ExecutorException("ResultLoader could not load lazily. DataSource wa= s not=20 configured.");

Connection conn =3D ds.getConnection();

conn =3D wrapConnection(conn);

Transaction tx =3D txFactory.newTransaction(conn,

false);

return conf= iguration.newExecutor(tx, ExecutorType.= SIMPLE);

}


--00c09f972a55c69243047805ee53--