TCP Server questions
jeffrey....@gmail.com
Is it possible to know when I client disconnects from the TCP Server?
Jeffrey
Ewald
You can get quite a bit of information if you query the
INFORMATION_SCHEMA tables - I query INFORMATION_SCHEMA.SESSIONS to
find out which sessions are open on the TCP/IP server.
Perhaps you can open the database in a database explorer and view all
the different tables under INFORMATION_SCHEMA, there's a lot of
information there.
I hope that helps.
Regards
Ewald
Jeffrey Krzysztow
Thanks for the information!
I was digging into the source code and there is also a memory database created for each TCP server. It too has SESSIONS.
I use dbSolo as a database explorer and not sure what I am seeing in this table. I know I have more than one connection, but this does not seem to be as far as the table is concerned. Hope Thomas can shed some light!
Jeffrey
Thomas Mueller
What is your use case?
> if there are clients connected to a TCP Server
It's possible, but not an official feature, and not documented. As you
already know, there is an in-memory "management_db_<port>" for each
TCP server. This database has a SESSIONS table. This table contains
one row for each connected session (this does work for me).
> when I client disconnects from the TCP Server
You could create a trigger on the SESSIONS table.
Regards,
Thomas
Jeffrey Krzysztow
On Thu, Apr 15, 2010 at 12:50 PM, Thomas Mueller <thomas.to...@gmail.com> wrote:
Hi,
What is your use case?
I need to know whether there are any connections to the database to prevent the database TCP server from shutting down. See below for more information.
It's possible, but not an official feature, and not documented. As you
> if there are clients connected to a TCP Server
already know, there is an in-memory "management_db_<port>" for each
TCP server. This database has a SESSIONS table. This table contains
one row for each connected session (this does work for me).
Is this different than the SESSIONS table in the INFORMATION_SCHEMA of the TCP connected database?
You could create a trigger on the SESSIONS table.
> when I client disconnects from the TCP Server
I thought it was not possible to have triggers on tables in the INFORMATION_SCHEMA. I have not tried this.
I would not know what connection was broken, just that *a* connection was broken. I need to know what connection was broken so I can remove records from a memory database that may pertain the that connection.
Specifically, I have a table used for locking "orders". If all goes well, this is managed by the application normally. If the application were to disconnect abnormally, I need to know which connect so I can remove the entry in the "locked orders" table.
Lastly, I need to know if there are still connections and provide a nice way to know who is connected.
I was thinking that maybe the DatabaseEventListener could have a connectionStarted(<Session ID>) and connectionStopped(<Session ID>).
Is there any way to get the <Session ID> for the current connection?
Jeffrey
Thomas Mueller
> Is this different than the SESSIONS table in the INFORMATION_SCHEMA of the
> TCP connected database?
Yes. This table is in the PUBLIC schema. You can add triggers. But
what you want to do (at least it sounds like that's the case) is just
call SELECT * FROM SESSIONS.
> I would not know what connection was broken, just that *a* connection was
> broken. I need to know what connection was broken so I can remove records
> from a memory database that may pertain the that connection.
Connections don't have a "good" unique identifier except toString().
How could you find out which one? Maybe using a debugger.
> I was thinking that maybe the DatabaseEventListener could have a
> connectionStarted(<Session ID>) and connectionStopped(<Session ID>).
I will add a feature request for
"DatabaseEventListener.openConnection(id) and closeConnection(id)."
However I will not have time to implement that currently.
> Is there any way to get the <Session ID> for the current connection?
conn.toString()
Regards,
Thomas
Jeffrey Krzysztow
> Is this different than the SESSIONS table in the INFORMATION_SCHEMA of the
> TCP connected database?
Yes. This table is in the PUBLIC schema. You can add triggers. But
what you want to do (at least it sounds like that's the case) is just
call SELECT * FROM SESSIONS.
I am running with 1.2.37 and the SESSIONS table is in the INFORMATION_SCHEME of the connected database. Am I looking at incorrect data?
Connections don't have a "good" unique identifier except toString().
> I would not know what connection was broken, just that *a* connection was
> broken. I need to know what connection was broken so I can remove records
> from a memory database that may pertain the that connection.
How could you find out which one? Maybe using a debugger.
So the Session ID from the SESSION table is part of the toString()?
I will add a feature request for
> I was thinking that maybe the DatabaseEventListener could have a
> connectionStarted(<Session ID>) and connectionStopped(<Session ID>).
"DatabaseEventListener.openConnection(id) and closeConnection(id)."
However I will not have time to implement that currently.
If you can give a bit of guidance to where this would go, I will be more than happy to implement and return patches.
Jeffrey
Thomas Mueller
> I am running with 1.2.37 and the SESSIONS table is in the INFORMATION_SCHEME
> of the connected database. Am I looking at incorrect data?
There is *also* a table called INFORMATION_SCHEMA.SESSIONS, but that's
not the table I'm talking about. I'm talking about PUBLIC.SESSION.
As you already know, there is an in-memory database
"management_db_<port>" for each TCP server. This database has a
PUBLIC.SESSIONS table. You need to open that database within the
server, not the client. Maybe add ;IFEXISTS=TRUE to the database URL
to ensure you don't create a new database without knowing. For me, the
database URL is:
jdbc:h2:tcp://localhost/mem:management_db_9092;ifexists=true (user sa,
and password empty unless you set the password when starting the TCP
server).
Regards,
Thomas