db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wujek Srujek <wujek.sru...@gmail.com>
Subject Re: Derby 10.8.2.2, JTA on GlassFish 3.1.2.2 and very strange behavior
Date Mon, 18 Feb 2013 16:22:13 GMT
Ok, so I was wrong all along. There seems not to be any explicit method to
start a local transaction in jdbc, it is implicit when a previous
transaction is committed (in JTA, though, I need to start it myself if I
manage the tx boundaries myself, and that perplexed me ;d). When I change
the autoCommit setting, the current transaction is committed, and a new is
started. Also, in my code, I ignored the SQLException when
connection.close() was called (it's not production code, just some testing,
but still a bad thing to do), and derby does throw a meaningful exception
there (saying that the transaction is still active), which is very nice.
One more question, though: the uncommitted insert comes up in the
subsequent select - is this data coming from the server, from the active
tx, or does the jdbc driver cache the data somehow?

wujek



On Mon, Feb 18, 2013 at 4:48 PM, Bryan Pendleton <bpendleton.derby@gmail.com
> wrote:

> On 02/18/2013 07:40 AM, Wujek Srujek wrote:
>
>> Hi. But why is there any local transaction? I haven't started any, I just
>> set autoCommit to false
>>
>
> There is always a transaction; Derby won't let you ever
> access the database without one.
>
> What auto-commit does is to automatically commit the
> transaction after each statement is executed.
>
> But any time you issue a statement against the database,
> if there isn't already a transaction begun, one is started
> for you.
>
> thanks,
>
> bryan
>
>
>

Mime
View raw message