Well, because we don't have a strong agreement how it should behave
AND nobody even cared until today :D, I'll leave it as is. We can
always revisit this later.
--
Jiri {x2} Cincura (x2develop.com founder)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
>> You could also see it from a different point: some part of your code is
>> misbehaving (ie not releasing connections back to the pool in a timely
>
> Interesting. I would say why your code isn't going to be fixed in
> first place? And should the library offer tools for this in first
> place?
>
On Thu, 25 Apr 2013 10:46:55 +0200, Jiri Cincura
wrote:
> On Thu, Apr 25, 2013 at 10:27 AM, Mark Rotteveel
> wrote:
>> You could also see it from a different point: some part of your code is
>> misbehaving (ie not releasing connections back to the pool in a timely
>
> Interesting. I would say wh
On Thu, Apr 25, 2013 at 10:27 AM, Mark Rotteveel wrote:
> You could also see it from a different point: some part of your code is
> misbehaving (ie not releasing connections back to the pool in a timely
Interesting. I would say why your code isn't going to be fixed in
first place? And should the
> why not to first close connections you're holding and then clean pools. Right?
Right 100%, from my point of view.
If - at any time during my application is executed - I don't have the
information about which connections I have instantiated and which of
them are probable open, then in any ca
On Thu, 25 Apr 2013 10:16:33 +0200, Jiri Cincura
wrote:
> How I'm thinking. The connections are normally in pool, when you're
> using some, it's not in pool (actually it's still in the pool's
> collection, but "marked as used") logically. When you're cleaning all
> pools you are cleaning connectio
How I'm thinking. The connections are normally in pool, when you're
using some, it's not in pool (actually it's still in the pool's
collection, but "marked as used") logically. When you're cleaning all
pools you are cleaning connections that are pooled (in pool). Hence
connections not in pool shoul
> On this ^ line you'll get exception as the connection1 was also
> cleared aka closed/disposed. I always used ClearAllPools with all
> connections closed so I had no idea it behaves like that.
Interesting, I also never noticed.
> But do you think is correct? Should the ClearAllPools clear even t
On Wed, 17 Apr 2013 10:29:57 +0200, Jiri Cincura
wrote:
> Hi *,
>
> I just found behavior that surprised me. Suppose pooling is on and
> (all connections to same database):
> Open connection1.
> Open connection2.
> Close connection2.
> FbConnection.ClearAllPools();
> Try to use connection1.
>
>
ClearAllPools should not close/dispose open connections.
A function to close all pooled connections might be useful however for when
you need to close all connections maybe with different name like
CloseAllPooledConnections
On Wed, Apr 17, 2013 at 10:29 AM, Jiri Cincura wrote:
> Hi *,
>
> I jus
Hi *,
I just found behavior that surprised me. Suppose pooling is on and
(all connections to same database):
Open connection1.
Open connection2.
Close connection2.
FbConnection.ClearAllPools();
Try to use connection1.
On this ^ line you'll get exception as the connection1 was also
cleared aka clo
11 matches
Mail list logo
