Does Firebird allow dirty reads? If so, you could check in an after
trigger, and the client could try again.

-----Original Message-----
From: nagypapi [mailto:nagypapi@...]
Sent: Tuesday, January 11, 2005 5:41 PM
To: Firebird-Java@yahoogroups.com
Subject: [Firebird-Java] Re: Transaction concurrency

> Not 100% correct. You have to specify the table to reserve in

so-called TPB.

> JayBird hides Firebird specifics under transaction isolation,

however you

> cannot reserve the table via JDBC API yet (please fill feature

request).

I was taking a peek at the Jaybird API and found the
FirebirdConnection ->
public void setTransactionParameters(int isolationLevel,
int[] parameters) throws java.sql.SQLException

Now the API doesn't say who I am to fill the parameters array It just
says "parameters - array of TPB parameters, see all TPB_* constants."
I took a look at the TPB parameters but didn't get any wiser, so I
took a look at the Interbase APIguide.pdf page 63 and saw that there
were different(more) constants mentioned there :tpb_shared / exclusive
/ lock_read / lock_write
My questions (or are they documented somewhere?):
-How do I set the parameters array?
-Are the constant's meanings exactly the same as in the apiguide?
-Are the other tpb_ constants going to be implemented?
-Should I use this instead of the
connection.setTransactionIsolation(...)?

And whilst looking at the SET TRANSACTION part in the language
reference and combining it with the info from embedsql.pdf I found t
hat what I need is the reserving clause:
"
To change the level of shared access for one or more individual tables
in a transaction.
For example, a READ WRITE SNAPSHOT transaction may need exclusive
update rights for a
single table, and could use the RESERVING clause to guarantee itself
sole write access to
the table.

PROTECTED READ Prevents other transactions from updating rows. All
transactions can select
from the table.
PROTECTED WRITE Prevents other transactions from updating rows.
SNAPSHOT and READ COMMITTED transactions can select from the table,
but only
this transaction can update rows.
SHARED READ Any transaction can select from this table. Any READ WRITE
transaction can
update this table. This is the most liberal reservation mode.
SHARED WRITE Any SNAPSHOT or READ COMMITTED READ WRITE transaction can
update this table.
Other SNAPSHOT and READ COMMITTED transactions can also select from this
table.
"

So what best suits my needs is non-autocommit mode and setting the
transaction in an sql statement to snapshot isolation level with
PROTECTED WRITE reservation clause

Phew... quite a lot of documentation jumping around. I guess this is
what Helen's book is for

Wouldn't have got here without your help (wouldn't have known that
setting a transaction's isolation level is the thing I've got to look
into)
John






Yahoo! Groups Links