On 03/12/16 12:50, Hamish Moffatt ham...@risingsoftware.com
[firebird-support] wrote:
>
> I'm also seeing idle transactions in MON$TRANSACTIONS sometimes. That
> is presumably the cause of my big issue, which is that I am reading
> back old data from the db.
OK, here's where I'm confused. The l
On 03/12/16 00:59, 'Thomas Steinmaurer' t...@iblogmanager.com
[firebird-support] wrote:
> I also see a ton of connections on MON$ATTACHMENTS from the same thread
> in my application (MON$REMOTE_PID, MON$REMOTE_ADDRESS both the same)
> which also makes no sense.
Closing a connection implicitly w
> On 02/12/16 20:59, Dimitry Sibiryakov s...@ibphoenix.com
> [firebird-support] wrote:
>> 02.12.2016 8:56, Hamish Moffatt ham...@risingsoftware.com [firebird-support]
>> wrote:
>>> I understand that the idle statement
>>> means they have been prepared but not executed, but this shouldn't be
>>> po
On 02/12/16 20:59, Dimitry Sibiryakov s...@ibphoenix.com
[firebird-support] wrote:
> 02.12.2016 8:56, Hamish Moffatt ham...@risingsoftware.com [firebird-support]
> wrote:
>> I understand that the idle statement
>> means they have been prepared but not executed, but this shouldn't be
>> possible i
02.12.2016 8:56, Hamish Moffatt ham...@risingsoftware.com [firebird-support]
wrote:
> I understand that the idle statement
> means they have been prepared but not executed, but this shouldn't be
> possible in my application source (prepare has never failed, and I
> always execute).
Yes, but af
Hi,
I'm trying to debug a concurrency issue I'm having with an application
of mine, connecting to Firebird 2.5.6, so I'm trying to understand the
various monitor tables. I have dozens of threads all making their own
connections to Firebird (superserver).
After running for a while my MON$STATEM