> It should be allowed. If this is not the case then
> it is bug either in
> your application logic or Jaybird driver. The latter
> is unlikely.

I know this is an imposition on your time and I truly
apologize for this. If I do not resolve this issue, I
will have to use MySQL and I like what I see in
Firebird. Please see the attached FirebirdTest.java
file and if something glares at you right off the bat
please let me know. I doubt there is something wrong
with that code. AFAIK its standard JDBC code that I
have tested with Oracle and MySQL.

Please execute this code if you find the time and with
more than 3 concurrent threads trying to update you
will see the application go in a perrenial loop.

I have stepped through Jaybird with a Debugger and I
think Firbird keeps sending back the same error when I
retry the insert on the same transaction. If however,
I commit or rollback, the next update goes thru fine.

> >> Use explicit pessimistic locks and
> >> isc_tpb_read_committed+isc_tpb_wait+<whatever>
> >> isolation mode to avoid
> >> the error or handle this error yourself via
> retring
> >> statement
> >> (isc_tpb_read_committed modes) or transation
> >> (isc_tpb_concurrency).
>
> > Even if I specify tpb_wait, If I understand
> correctly,
> > Firebird will report an update failure once the
> first
> > update commits. So wait/nowait only differ in when
> > Firebird reports a conflict, right?
>
> wait/nowait mode specify if Firebird is allowed to
> wait on locks.
> Normal updates are not protected from update
> conflicts in any TPB
> mode. You can have some guaranties only if you
> precede them with
> appropriate explicit lock statement. You can read
> README.explicit_locks for explanation of some
> points.
>

I am not communicating my issues clearly. I do not
need/want pessimistic locking. I think the transaction
based locks with versioning provided by FB are
perfect. I have read most of the articles that explain
transaction management in FB and I have also read
Interbase 6.0 documentation.

All I want to do is whenever I get an update conflict,
sleep for a while and then retry the update.

> BTW, if you handle update conflicts without rolling
> back full
> transaction your application may also benefit from
> using of
> savepoints.
>

First, the intent of the application is to allow
concurrent updates. So I do not want to rollback in
case of update conflict, I just want to retry the
update.

I cant use savepoints either! I am working on an EJB
Application that uses Container Managed Persistence
Entity Beans where all sql is declarative and the
transaction management is declarative. As you probably
know, the J2EE containers' transaction manager will
handle all commits and rollbacks, so I do not actually
control a commit/rollback.

FYI, this application is currently live on Oracle and
I am tasked with choosing an Open Source database. On
oracle, our application handles well over 100
concurrent requests and involves interactions with
other XA and non-XA compliant data sources. Firebird
is the only Open Source database with a XA JDBC driver
and I would LOVE to use firebird but if I cant handle
concurrent orders, then its a no show for me.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com