Hi!
2011/7/4 Vincent de Phily <vincent.dephily@mobile-devices.fr>:
> On Monday 04 July 2011 10:48:48 Durumdara wrote:
>> 1.) DataBases need to close the resources kept by Sessions.
>> 2.) There is need some "border", or a rule to split - which Session is
>> considered as "finished".
>
> So far so good.
...so what! (Megadeth).
:-)
>> Another thing is sign (packet). We must do something periodically to
>> keep alive the connection. For example: every 1 minutes we do some
>> dummy thing one server, like "select date" or etc.
>
> AFAIK postgres doesn't distinguish between a "TCP session" and a "database
> session" like (if I understand you correctly) FireBird/EDB does. You cannot
> reconnect and say "hello it's me again from session FOOBAR, can I resume that
> session ?". I believe you'll have to solve this at the application layer :
>
> * Make transactions, locks, temp tables, etc as short-lived as possible (this
> is always a good thing to do anyway).
> * If that's still not enough, store your "current working state" in a purpose-
> built table and add logic in your client to reinitialize session state
> using that data, and to purge the data after it has been used / timed out.
>
> Another thing you could do (but I'm not sure it is a good idea) is to write a
> proxy application that runs on the server machine and understands your session
> requirements. Then connect your application to this proxy instead of the
> database.
Thanks for your information.
And then I ask the question that is remaining hidden in prev. mail:
What happens with running statements and stored procs at Session's end?
They will be aborted and destroyed, or they can continue the running?
For example:
User X starts a long Query/STP.
But he is lost "in deep space" (like in "Space Oddity":
http://www.youtube.com/watch?v=rKE3FSPJu-4&feature=related).
The TCP connection aborted, then the Session is set to dead.
But I don't know what happens with this Query? Is it aborted by Server
or Running may infinitively?
Thanks:
dd
