Hello, Nitin,

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

Cannot reproduce it. Here is the example of my output:
-------------------------------
D:\Test15>java -cp d:\azk2\server\lib\activation.jar;d:\azk2\server\lib\avalon-framework.jar;d:\azk2\server\lib\classes12.zip;d:\azk2\server\lib\firebirdsql.jar;d:\azk2\server\lib\JSQLConnect.jar;d:\azk2\server\lib\junit.jar;d:\azk2\server\lib\logkit.jar;d:\azk2\server\lib\mail.jar;d:\azk2\server\lib\mini-j2ee.jar;d:\azk2\server\lib\openorb-1.4.0.jar;d:\azk2\server\lib\tools-1.4.0.jar;d:\azk2\server\lib\xercesImpl.jar;d:\azk2\server\lib\xmlParserAPIs.jar;D:\azk2\Server\tools\lib\openorb_tools-1.4.0.jar;D:\azk2\Server\lib\firebirdsql.jar;D:\azk2\Server\AzkServer.jar;classes FirebirdTest 7
Thread 0==> started
Thread 1==> started
Thread 2==> started
Thread 3==> started
Thread 4==> started
Thread 5==> started
Thread 6==> started
Thread 0==> udpating....
Thread 1==> udpating....
Thread : Thread 1 Exception on update : GDS Exception. deadlock
update conflicts with concurrent update
Thread 1==> udpating....
Thread 0==> after commit....
Thread 0==> end
Thread 1==> after commit....
Thread 1==> end
Thread 2==> udpating....
Thread 2==> after commit....
Thread 2==> end
Thread 3==> udpating....
Thread 3==> after commit....
Thread 3==> end
Thread 4==> udpating....
Thread 4==> after commit....
Thread 4==> end
Thread 5==> udpating....
Thread 5==> after commit....
Thread 5==> end
Thread 6==> udpating....
Thread 6==> after commit....
Thread 6==> end
---------------------------------------

I only added change to report tId instead of thread name in exception
handling block. Tested against Firebird 1.5 Win32 RC6 CS and Firebird
1.5 Win32 RC6 SS and Jaybird version around 1.0. As you can see - no
unbounded loop happens - exception is cleanly handled.

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

^^^^^^ which insert ?

> I commit or rollback, the next update goes thru fine.



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

No need to sleep if you are already using isc_tpb_wait modes.

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

Ok, I look at this from the insider POV as I'm also designer/developer
of one application server. And this AS makes use of savepoints (to
handle backing out of declarative nested transactions) and explicit
locks (to coordinate access to objects when AS is used in clustered
environment) during its operation.

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

It can, believe me.


--
Nickolay Samofatov