On 30-5-2015 10:49, Maxim Smyatkin wrote:
Oh, and it worth mentioning - I tried it only with latest FB 2.5
It breaks with Firebird 3 (a snapshot of last week). The test
TestFBDatabaseMetaData.testGetProcedureColumns hangs when executed
against Firebird 3: the entire server hangs.
The test
On 5/31/2015 5:33 AM, Dimitry Sibiryakov wrote:
31.05.2015 9:17, Mark Rotteveel wrote:
The problem is probably that there is still an active transaction at
that point, where before it was already committed or rolled back.
Prepared statements are not bound to a transaction, they (and I
On 30-5-2015 21:54, Maxim Smyatkin wrote:
Yes, it makes sence. I was wrong as the procedure still depends on the
table, so it's the intented behaviour. But what I still can't understand
is why did it work before? I mean, old tests were using Jaybird's
AutoCommitTransaction which is just a
31.05.2015 9:17, Mark Rotteveel wrote:
On 30-5-2015 21:54, Maxim Smyatkin wrote:
Yes, it makes sence. I was wrong as the procedure still depends on the
table, so it's the intented behaviour. But what I still can't understand
is why did it work before? I mean, old tests were using Jaybird's
31.05.2015 12:33, Dimitry Sibiryakov wrote:
Prepared statements are not bound to a transaction, they (and I believe their
existence
locks) exists till explicitly unprepared/freed or connection ends.
Existence locks are bound to *both* statement and transaction lifetime.
Dmitry
Yes, it makes sence. I was wrong as the procedure still depends on the
table, so it's the intented behaviour. But what I still can't understand is
why did it work before? I mean, old tests were using Jaybird's
AutoCommitTransaction which is just a wrapper around Manageable
transaction, so it
On 29-5-2015 16:10, Maxim Smyatkin wrote:
Hello,
Recently we've got an information from some company that they would like
to use Firebird/Red Database with OpenCMS, but they couldn't afford it
because of bad performance. We compared it with PostgreSQL and it was
true - on some page views PG
Yes, that's right. Commit_retaining doesn't release acquired resources and
it shouldn't. But I still believe it's a bug in the Firebird itself,
because procedure after creation should decrement relation use count, but
it doesn't. Any of the steam blob tests fail even when executed separetely.
On 30-5-2015 10:21, Maxim Smyatkin wrote:
Surely I would like to see the same optimization in Jaybird 3, but I'm
currently more interested in 2.2.*.
I understand and it will end up in 2.2, just not in 2.2.8 ;). This
change has some implications that I need to understand better before I
can
Oh, and it worth mentioning - I tried it only with latest FB 2.5
On Sat, May 30, 2015 at 11:33 AM, Mark Rotteveel m...@lawinegevaar.nl
wrote:
On 30-5-2015 10:21, Maxim Smyatkin wrote:
Surely I would like to see the same optimization in Jaybird 3, but I'm
currently more interested in 2.2.*.
29.05.2015 17:10, Maxim Smyatkin wrote:
2. Whole TestFBBlobStream family (6 tests) fails. The reason is bug in
Firebird transaction engine. When transaction started in
auto-commit mode actually commits (via commit_retaining) it doesn't free any
resources. E.g., what happens in these tests
29.05.2015 17:10, Maxim Smyatkin wrote:
- we create a procedure P using a table T.
- the P states its interest in the T (while looking for P's dependencies);
- transaction commits the changes with retaining flag and forgets to say
that it isn't interested in the T anymore;
Externally (for
Hello,
Recently we've got an information from some company that they would like to
use Firebird/Red Database with OpenCMS, but they couldn't afford it because
of bad performance. We compared it with PostgreSQL and it was true - on
some page views PG showed 4 seconds while for Firebird it was
message -
Van: Maxim Smyatkin smyatkinma...@gmail.com
Aan: firebird-devel@lists.sourceforge.net
Onderwerp: [Firebird-devel] Moving Jaybird auto-commit implementation into
Firebird
Datum: vr, mei 29, 2015 16:10
Hello,Recently we've got an information from some company that they would like
14 matches
Mail list logo
