Again, you haven't specified if you're talking about SQL. A lot of the
answers you get will probably assume you're using SQL, but there are other
query languages out there, and their behaviour can be different.

   Anyway, I believe that the "correct" behaviour in SQL is that the SELECT
statement in the different connection will NOT get the updated value.

   But again, in practice, things might be different. I believe the MySQL
RDBM does not correctly implement transactions, and so "non-committed"
updates WILL affect the select in another connection (because actually all
UPDATEs are committed, even if you request them not to be).

   - Oliver

Depends upon the transaction isolation level. See:

http://download.java.net/jdk6/docs/api/java/sql/Connection.html#setTransactionIs
olation(int)

For the various options

TRANSACTION_SERIALIZABLE - This does what you expect. Attempting to
think about the implications of other isolation levels is not good for
your mental health. (The standard technique for dealing with other
isolation levels is to not bother thinking about it.) However,
performance, particularly on huge transactions like nightly reports, can
suffer.

TRANSACTION_REPEATABLE_READ - This may see the committed update
statement. However, the other transaction either sees an altered row or
it doesn't. If the transaction found the row in a select before the
update statement, any further selects will see the original row. It will
not see uncommitted updates.

TRANSACTION_READ_COMMITTED - The select transaction *may* see the
updated rows, even if it read the old values. It will not see
uncommitted updates.

TRANSACTION_READ_UNCOMMITTED - It may see the uncommitted update.

TRANSACTION_NONE - Commit is not supported.

You said in another post you were using Oracle. The default is
TRANSACTION_READ_COMMITTED, so the uncommitted update will not be read.
Even so, I suggest switching the transaction isolation level to
TRANSACTION_SERIALIZABLE unless you absolutely must change that.

Tom Hawtin