"
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
J

> 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: 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