Re: (Mis)use of transactions

RedGrittyBrick wrote:

In the JPanel's constructor I get a java.sql.Connection instance and thus open a connection to the DBMS.

Sounds like very confused code to me. Is it a UI class or a database class? In any case, I'd avoid subclassing unnecessarily.

However if the user does a few changes and then wanders off for lunch, the database table is left in a locked state that obviously is likely to cause problems for other users (or other threads in the user's app).

And quite possibly the connection times out causing all of the users data to be discarded. I'm guessing most people don't like it when that happens.

Maybe I should do the getConnection(), executeUpdate(), close() for each little change to a table row and remove the "Cancel" button?

No particular need to close each time, although it is worth being able to reopen then connection if it fails.

From a usability perspective I like applications that are as immediate as possible. That means no OK/Cancel buttons. However, if you want locking you can still implement your own locking system on top of the database.

There is a problem in that updates that other actors make while the window is open wont be automatically shown. You can do that relatively efficiently by putting triggers on the main table that copy updates into shadow tables.

Tom Hawtin
.