Submitted by: Bill Oliver (verbguy)

Relate to CORE6382

Votes: 1

2 connections in ISQL. The first connection creates a table and inserts a record. The 2nd attemps to drop the table. The 2nd user hangs.

The "hang" occurs only in Classic or Embedded mode. This was found in testing Vulcan embedded. In other locking modes, the 2nd user gets "OBJECT IN USE" message, much better.

Here it is expressed w ISQL:

TX1> create database 't3.fdb';
TX2> connect 't3.fdb';
TX1> create table t (I integer);
TX1> insert into t values (3);
TX1> commit;
TX2> commit;
TX1> insert into t values (4);
TX2> drop table t; <HANG>

Dmitry confirmed this issue and said:

You create/attach the database using local connection string, so the FB server handles both connections via XNET, i.e. superserver with a shared cache is in game. In debugger, I see that relation->useCount == 2, so the LCK call just doesn't happen, hence no delay/hang. And I see the same for Vulcan, if it's used in the server mode (via localhost).

However, your test case involves the Vulcan embedded mode by default, causing two processes to share a database file through the lock manager. This is equal to FB classic server mode. And I see exactly the same behaviour if running your test case against fb_inet_server. So, in fact, this is not a regression in Vulcan, but some issue inherited from the Borland times.

While I agree it's worth fixing, I'm not ready to assign it a high priority at the moment, sorry.