Subject | Re: [firebird-support] Multi-threaded apps and pooled connection question |
---|---|
Author | Ann W. Harrison |
Post date | 2005-09-07T16:09:35Z |
Greg At ACD wrote:
first insert is committed, and the subsequent select is done from a
transaction that starts after the commit, the select will see the
results. Absolutely. My guess is that you're using a read committed
transaction (which I wouldn't) and that each connection starts a
transaction as soon as it commits the previous transaction. Or perhaps
that connections just hang around loose with open transactions.
Regards,
Ann
>If that's happening, you're not doing your commits correctly. If the
> Now, I have a situation where I have one connection service
> an "insert into <table>..." request, and returns a PK for the new
> record ...
>
> After a short amount of time, the client then uses this PK and makes
> a request to the back end (select ... from <tablewhere id = <new pk
> value>). It so happens that a different connection is used from the
> connection pool, and the call comes back with an empty result (i.e.
> the second connection doesn't see the data that was added in the
> first connection). If I wait a second or so, then the 2nd connection
> will return the correct data.
first insert is committed, and the subsequent select is done from a
transaction that starts after the commit, the select will see the
results. Absolutely. My guess is that you're using a read committed
transaction (which I wouldn't) and that each connection starts a
transaction as soon as it commits the previous transaction. Or perhaps
that connections just hang around loose with open transactions.
Regards,
Ann