Return-Path: Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 76024 invoked by uid 99); 6 Feb 2005 16:58:46 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of clinton.begin@gmail.com designates 64.233.184.199 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.199) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 06 Feb 2005 08:58:43 -0800 Received: by wproxy.gmail.com with SMTP id 69so607975wra for ; Sun, 06 Feb 2005 08:58:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=inFOB6vYSVy3WEkQPYyvqBcadV4UGPu/BZMgYY6tCDBUzS7907nodyW9JgyBt3HHSXV2hP/ESeZb23xjQ/EacMqR09S8PYY6EBCpOM0JAePZIjaksjUrsIWlC8O9/g1CqwG2FT6OIO172PKxwOcb0VIW9ecQn7qMVDXOusw/7Mk= Received: by 10.54.50.3 with SMTP id x3mr72829wrx; Sun, 06 Feb 2005 08:58:41 -0800 (PST) Received: by 10.54.33.30 with HTTP; Sun, 6 Feb 2005 08:58:41 -0800 (PST) Message-ID: <16178eb105020608586c7aa4a1@mail.gmail.com> Date: Sun, 6 Feb 2005 09:58:41 -0700 From: Clinton Begin Reply-To: cbegin@ibatis.com To: ibatis-user-java@incubator.apache.org Subject: Re: iBatis and EJB In-Reply-To: <4205C7CC.4070500@isanusi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050205223119.85963.qmail@web52207.mail.yahoo.com> <420565CC.70501@isanusi.com> <4205958D.2050507@friendvu.com> <4205C7CC.4070500@isanusi.com> X-Virus-Checked: Checked > it is possible to create *one* implementation of a DAO that behaves > differently when under > an EJB context and differently when *outside* an EJB context? Absolutely. Your Java source will not have to change, only the transaction manager configuration. You can choose to use a JTA or EXTERNAL transaction manager type for working with declarative transactions (depends on your server, configuration etc.). When using local transactions, you use the JDBC tranaction manager. In all cases you follow the same try/finally start/commit/end paradigm. Calling commit with a JTA transaction may or may not commit depending on the existing context, whereas EXTERNAL will NEVER commit and depends completely on an external transaction manager. Clinton On Sun, 06 Feb 2005 09:31:24 +0200, Abdullah Kauchali wrote: > > > friendVU admin wrote: > > > Did you ask if distributed 2 phase commits are done without EJB? > > Of course! You can do that in iBatis by itself. And in Tomcat or Resin > > by itself. > > sqlMap or JBDC.commit() or rollback(). > > Or even in SQL by itself. > > > > No, no ... I know we can do 2-phase commits without EJB's. What I'm > asking is whether > it is possible to create *one* implementation of a DAO that behaves > differently when under > an EJB context and differently when *outside* an EJB context? > > I'll give you an example: > > Suppose there is an insertProducts SQLMap with its appropriate DAO class > that manages > the execution of the insert statement *but* in a local transaction > scenario only. Now, > suppose we want to expose that same SQLMap to other development > environment that > want to participate with insertProducts transactionally but with 2PC. > Is it possible to wire only the > EJB specific classes on top and deploy it, or do you have to create an > entirely separate > DAO that has EJB logic in it and then dish out that new API to the > external developers? > > Sorry for the confusion .... It's not a serious question ... yet ...I am > under stress here on > another stupid project ... I keep reading the iBatis stuff because it is > too interesting. :) > > Regards > > Abdullah >