Subject | Re: [Firebird-Java] Re: Jaybird 'object in use' error adding ref integrity constraint |
---|---|
Author | Nickolay Samofatov |
Post date | 2002-10-02T10:07:15Z |
Hello Roman,
Wednesday, October 02, 2002, 2:38:30 AM, you wrote:
more locking in isc_tpb_consistency mode. Existance of prepared statement
on one connection prevents any DDL modification of any object it uses
even on this connection - this is by design. If there is some kind of
resource leak when statement doesn't get closed nobody will be able to
do any DDL on objects it uses until you restart the server.
point to isc_tpb_consistency mode problems (buggy code works in other tools,
server was cleanly restarted before trying it in Jaybird, etc).
I tested DDL a lot in isc_tpb_concurrency mode using FB1 and Jaybird and
it makes almost no problems if you restart server often enough (usually every 30-50
DDL statements) and use only one connection.
started reporting OBJECT "INDEX"/"<tablename>" IN USE on DDL
statements until you restart server after very many operations.
Look at the recent changelog - there was ~15 different bugs there.
There are still some resource leaks in FB2 DDL procedure handling
code. I will look at it very soon.
Best regards,
Nickolay Samofatov mailto:skidder@...
Wednesday, October 02, 2002, 2:38:30 AM, you wrote:
> Hi,There is locking. When engine does internal DDL queries it does
>> It is very possibly related with isc_tpb_consistency mode if it is
>> used.
> Why should it? If this statement is executed using one connection
> there is no concurrency here. Statements are executed one by one,
> within a context of one transaction in non-autocommit mode, or
> different but serially ordered transactions.
more locking in isc_tpb_consistency mode. Existance of prepared statement
on one connection prevents any DDL modification of any object it uses
even on this connection - this is by design. If there is some kind of
resource leak when statement doesn't get closed nobody will be able to
do any DDL on objects it uses until you restart the server.
> If statements are executed each in its own connection (like getThis code would be very helpful. But conditions when it occurs may
> connection from the pool, execute statement, return connection to the
> pool), such problem cleanly points out on the bug in either pool
> implementation, or our transaction management. That is why I asked for
> the code that causes this bug.
point to isc_tpb_consistency mode problems (buggy code works in other tools,
server was cleanly restarted before trying it in Jaybird, etc).
I tested DDL a lot in isc_tpb_concurrency mode using FB1 and Jaybird and
it makes almost no problems if you restart server often enough (usually every 30-50
DDL statements) and use only one connection.
> Also, I do remember that engine had some problems with "object is inI fixed most of that problems in FB1.5 Alpha 1. Basically server
> use", but I do not know if they were corrected in FB 1.0 or not. As a
> workaround people suggested to execute DDL statements in autocommit mode.
started reporting OBJECT "INDEX"/"<tablename>" IN USE on DDL
statements until you restart server after very many operations.
Look at the recent changelog - there was ~15 different bugs there.
There are still some resource leaks in FB2 DDL procedure handling
code. I will look at it very soon.
> Best regards,--
> Roman Rokytskyy
Best regards,
Nickolay Samofatov mailto:skidder@...