From user-java-return-15392-apmail-ibatis-user-java-archive=ibatis.apache.org@ibatis.apache.org Thu Oct 09 14:07:33 2008 Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 84656 invoked from network); 9 Oct 2008 14:07:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2008 14:07:33 -0000 Received: (qmail 64531 invoked by uid 500); 9 Oct 2008 14:07:31 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 64345 invoked by uid 500); 9 Oct 2008 14:07:30 -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 64334 invoked by uid 99); 9 Oct 2008 14:07:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2008 07:07:30 -0700 X-ASF-Spam-Status: No, hits=2.7 required=10.0 tests=DNS_FROM_OPENWHOIS,DNS_FROM_SECURITYSAGE,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2008 14:06:26 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KnwAP-00033X-SC for user-java@ibatis.apache.org; Thu, 09 Oct 2008 07:07:01 -0700 Message-ID: <19899728.post@talk.nabble.com> Date: Thu, 9 Oct 2008 07:07:01 -0700 (PDT) From: mule_user To: user-java@ibatis.apache.org Subject: Re: IBATIS 2.3.3, JDK 1.5 - Optimistic locking strategies In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: sgho@aol.com References: <19867989.post@talk.nabble.com> <19884010.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org My fundamental question was: Is there a way to achieve optimistic locking, if the "OldObject" and/or the update timestamp of the old object were NOT available in scope. It seems that the solution in iBATIS requires you to keep the "OldObject" in scope because, the where clause requires you to pass the ID of the "OldObject" and update timestamp of the "OldObject". Otimistic locking requires keeping "OldObject" in scope in JDBC. I have followed this principle using JDBC for years. I understand that iBATIS is built upon data mapping, not ORM. That being said, I was hoping that there is an elegant solution using iBATIS, where I do not have to keep "OldObject" in scope. I was hoping that I do not have to resort back to keeping "OldObject" in scope, similar to the way I am used to doing it in JDBC realm. Again, keep in mind that I can only use timestamp attribute, not version. -- View this message in context: http://www.nabble.com/IBATIS-2.3.3%2C-JDK-1.5---Optimistic-locking-strategies-tp19867989p19899728.html Sent from the iBATIS - User - Java mailing list archive at Nabble.com.