Mailing lists / fpc-devel / 2015-04
Death of TSQLConnection instance after connection interrupt
10 messages · 2 people ·
- Michael Van Canneyt 5
- Чернов Дмитрий 5
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Чернов Дмитрий wrote 13 lines
Hello.
Recently I've used FPC with SQLdb that is included in latest Lazarus. And after some usage I've determined one inconvience: if connection to database server of instance of
TSQLConnection (or it's descendant) will be interrupred, instance will fall into a coma. This happens because of some reasons:
1) there is no way to determine whether connection is broken
2) no exceptions are thrown on connection interrupt
3) none of disconnection events are called on interruption
3) if you'll try to shutdown interrupted connection by setting Connected property of TSQLConnection to False, you will get exception about interrupted connection and after that...
property value will not be changed. so, you can't reconnect.
So, due to this reasons, currently there is only single way to raise the connection - manually re-create TSQLConnection component instance in run-time, what awful.
It seems that my english is entirely terrible, so excuse me in advance.
We are aware of this problem, and we are working on a solution to be able to reconnect (so, point 4 in your list (actually, the second 3) :))
See for example: http://bugs.freepascal.org/view.php?id=26505
There is a beginning of a patch in TCustomConnection
procedure Close(ForceClose: Boolean=False);if you set Force to True then the connection will be closed and errors will be ignored.
Michael.
Чернов Дмитрий wrote 25 lines
17.04.2015, 18:41, "Michael Van Canneyt" :
We are aware of this problem, and we are working on a solution to be able to reconnect (so, point 4 in your list (actually, the second 3) :))
See for example: http://bugs.freepascal.org/view.php?id=26505
There is a beginning of a patch in TCustomConnection
procedure Close(ForceClose: Boolean=False);
if you set Force to True then the connection will be closed and errors will be ignored.
Michael.
,
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
thanks for answer. it's really nice to report known bugs ;)
but I tried forced connection closedown, and it doesn't work. at least for me. or it's I'm just sad sack?
for example, I have this code on my (re)connect button:
http://pastebin.com/9PPyaby9
and after connection interrupt it throws "connection lost" exception on IBConnection.Close( True ), and doesn't set Connected to False
That is because this form of close requires implementation details per descendent of TCustomconnection
It has been implemented for MySQL (where 'Server has gone away' is a frequent problem), but not yet for Firebird. I will look into it.
also one small question. will it be possibly to determine whether connection was closed by user or interrupted? and what about events calling on interrupts?
We can think about this. The problem with an interrupt is that you don't know when it happens. You only see it when you try to do something new.
Michael.
Чернов Дмитрий wrote 14 lines
17.04.2015, 20:36, "Michael Van Canneyt" :
On Fri, 17 Apr 2015, Чернов Дмитрий wrote:
also one small question. will it be possibly to determine whether connection was closed by user or interrupted? and what about events calling on
interrupts?
We can think about this. The problem with an interrupt is that you don't know when it happens.
You only see it when you try to do something new.
Michael.
I believe that additional boolean argument for BeforeDisconnection event, that will show us if disconnection was caused by interrupt, could be nice solution.
That is not possible, it would break backwards compatibility.
Michael.
Чернов Дмитрий wrote 26 lines
18.04.2015, 00:00, "Michael Van Canneyt" :
On Fri, 17 Apr 2015, Чернов Дмитрий wrote:
17.04.2015, 20:36, "Michael Van Canneyt" :
On Fri, 17 Apr 2015, Чернов Дмитрий wrote:
also one small question. will it be possibly to determine whether connection was closed by user or interrupted? and what about events
calling on
interrupts?
We can think about this. The problem with an interrupt is that you don't know when it happens.
You only see it when you try to do something new.
Michael.
I believe that additional boolean argument for BeforeDisconnection event, that will show us if disconnection was caused by interrupt, could be nice
solution.
That is not possible, it would break backwards compatibility.
Michael.
oh, i'm sorry. forgot about it.
maybe then it's better to add OnInterrupt event?
When do you want to call such a hypothetical event ? As I said, there is no good way to detect when it happens:
Only when you do a new operation and the call returns an error, you will know after examining the exact error (which is an unsure operation) if it was 'interrupted'.
Michael.
Чернов Дмитрий wrote 11 lines
When do you want to call such a hypothetical event ?
As I said, there is no good way to detect when it happens:
Only when you do a new operation and the call returns an error,
you will know after examining the exact error (which is an unsure operation) if it was 'interrupted'.
Michael.
hmm. okay, got it.
thanks for such a positive feedback:)
well, what I will do is try to make the reconnect work in the IBConnection.
Michael.