Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <1176054740.46192bd4c4de3@webmail.jpox.org>
Date: Sun,  8 Apr 2007 10:52:20 -0700
From: Erik Bengtson <erik@jpox.org>
To: Apache JDO project <jdo-dev@db.apache.org>,
 JDO Expert Group <jdo-experts-ext@sun.com>
References: <1176039606.4618f0b60df35@webmail.jpox.org>
 <C668030C-07E3-4EF8-8BD0-C4580FC458C5@SUN.com>
 <1176047251.46190e9347503@webmail.jpox.org>
 <93C042FD-A943-4D4C-9122-8EA3A98F46BB@SUN.com>
In-Reply-To: <93C042FD-A943-4D4C-9122-8EA3A98F46BB@SUN.com>
MIME-Version: 1.0
User-Agent: Internet Messaging Program (IMP) 3.2.3
Subject: Re: DatastoreConnection / optimistic txs
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

> I'm afraid I don't know what you mean by "this feature" and "this
> change". If you want to guarantee that the datastore connection you
> get is enlisted in the JDO transaction

tx.setOptimistic(true)
tx.begin()
//do some operations here
JDOConnection conn = tx.getDataStoreConnection();
conn.getNativeConnection().execute("UPDATE TABLEB SET A=1");
conn.close();
tx.rollback();

A flush may or may not be performed before "getDataStoreConnection" gets
invoked. If a flush is performed, the connection is enlisted in the
transaction.

So, accessing the datastore connection and doing updates is not portable, since
the connection may or may not be enlisted in the transaction.

The side effect of my change proposal would make it portable since connections
are always enlisted in the transaction :)

> we can add a flag to guarantee it.

I'm in favor of breaking backward compatibility and not adding a new flag,
because currently it's not ACID neither portable.