Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 30564 invoked from network); 7 Feb 2007 12:33:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2007 12:33:50 -0000 Received: (qmail 65286 invoked by uid 500); 7 Feb 2007 12:33:53 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 65269 invoked by uid 500); 7 Feb 2007 12:33:53 -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 65258 invoked by uid 99); 7 Feb 2007 12:33:53 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 04:33:53 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of larry.meadors@gmail.com designates 64.233.184.230 as permitted sender) Received: from [64.233.184.230] (HELO wr-out-0506.google.com) (64.233.184.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 04:33:44 -0800 Received: by wr-out-0506.google.com with SMTP id i21so192354wra for ; Wed, 07 Feb 2007 04:33:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sOcy+Ii8Eie48PN6aExstR0ToTM4fzXUTOCD1WiAF+RAelsC5eeAtz1bPBU6obdtGn9lchHn4ulj4zm9KVEUW1AeDHfZ1FnHux3hyN+v0FONSwHI0ZMN2+xam2EM1kR5k8i5cwDoXmtKMTUx/oEsTH5xD1sytg/qUyVY7N9m/dE= Received: by 10.114.175.16 with SMTP id x16mr1632622wae.1170851603102; Wed, 07 Feb 2007 04:33:23 -0800 (PST) Received: by 10.114.183.6 with HTTP; Wed, 7 Feb 2007 04:33:23 -0800 (PST) Message-ID: Date: Wed, 7 Feb 2007 05:33:23 -0700 From: "Larry Meadors" Reply-To: lmeadors@apache.org Sender: larry.meadors@gmail.com To: user-java@ibatis.apache.org, "Abdullah Kauchali" Subject: Re: How does iBatis know which connection object to use from a pool? In-Reply-To: <28311532.1170840292784.JavaMail.root@dogbert> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28311532.1170840292784.JavaMail.root@dogbert> X-Google-Sender-Auth: 74485dcfd5f03139 X-Virus-Checked: Checked by ClamAV on apache.org All connectins and transactions are managed using thread local storage, so each thread has it's own connection, etc.. Larry On 2/7/07, Abdullah Kauchali wrote: > As I understand it, SqlMapClientImpl (SqlMapClient) hides or wraps the primary JDBC object, Connection. So, we can essentially do everything with SqlMapClient that we can with JDBC's Connection object (including starting, commiting or aborting transactions). However, with iBatis, we don't have to explicitly manage the life times of the Connection objects as we have to with JDBC's Connection object. That's groovy. :) > > Now, we also know that SqlMapClient can (and should) be configured as a (JVM) global variable either by using it as a simple static variable or through the singleton pattern. Given that each thread that accesses the global SqlMapClient variable gets a copy of it (for local work), how does iBatis know which connection object to retrieve from the pool - especially if the SqlMapClient [sic] is participating in a transaction and the correct connection object needs to be retrieved to chain the "transactionable" activities? > > Kind regards, > > A > > > > >