db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John English ...@brighton.ac.uk>
Subject Re: Locking problem
Date Sun, 17 Oct 2010 17:25:37 GMT
Bryan Pendleton wrote:
> To commit your transaction, you need to call Connection.commit() (or put
> your connection into auto-commit mode). Closing your result sets is
> desirable, but by itself it won't commit the transaction.

But it will commit if the connection is in auto-commit mode, right?

I've now gone through the whole of my code making sure all the places
where I turn off autocommit have a finally block to commit and then
turn it back on again, and I now close my result sets even when empty. 
If I'm correct above, this *should* do the trick...

> You should also close your statements when you no longer need them. Derby
> has finalizers for ResultSet, Statement, and Connection objects, but
> waiting for the Java garbage collector to collect your JDBC objects can
> be very problematic, as they can accumulate quickly and can hold quite
> a bit of resources. So it's good to keep in the habit of closing them
> as soon as possible.

OK; lots more try/finally blocks needed, then!

One thing I find: all this manual closing doesn't half complicate the
code! It's a bit like going back to C++... :-(

> Another thing you can do is to configure the transaction's isolation level;
> the default isolation level holds a lot of locks, and many applications
> find that they can run successfully using a lower level of isolation.

Hmm, maybe also worth a try. I'd better get it working first though!

Many thanks for your advice, yet again!

  John English              | mailto:je@brighton.ac.uk
  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
  School of Computing & MIS | "Those who don't know their history
  University of Brighton    |  are condemned to relive it" (Santayana)

View raw message