Subject Re: Transaction concurrency
Author nagypapi
Triggers operate within the context of the transaction in the program
where they are
fired. Triggers are considered part of the calling program's current
unit of work.
At least that is what the datadef.pdf says. If so, that means I still
need transaction isolation set, because the trigger as default,
wouldn't see the uncommited changes

> 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@f...]
> Sent: Tuesday, January 11, 2005 5:41 PM
> To:
> 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.
> 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