My solution has a need to rarely connect to a specific database. This connection only needs to occur from one specific page and that page is rarely used. Once or twice a week at most over thousands of users. How can I manage this connection so that it is only instantiated when needed and immediately closed when finished?
It look like the connection pooling would prevent this sort of granular control I’d like to have.
Gary
That’s not possible right now, you have to add the connection permanently in the servoy.properties file
Harjo:
That’s not possible right now, you have to add the connection permanently in the servoy.properties file
That part is clear. But does that make a “permanent” connection to the database server, even if the particular Servoy solution has no users currently attached? I have two separate Servoy Solutions on the server right now. They are not both active all day. Sometimes during the day folks are connected to one, the other, both or none.
The particular situation with this one solution is that it rarely needs the connection to the database in question, so it seems having the ability to use something like the databasemanager object (or some other mechanism) to tell the Servoy engine that a connection is now needed and then tell it to free the connection would be a much better management of resources over having a constant connection made “just in case” it is needed.
I’m coming form the “client- server” world where such management of connections, even via a connection pool, is just the norm and considered a best practice.
Gary
Hi Gary,
There is a difference between the definition of the connection pool and the actual open connections.
The moment you want to access objects from a connection Servoy will open a new connection when not available and close it again when idle.
But you can also set the maximum idle connections to stay open for re-use so you don’t have the overhead of opening the connection. I guess in your use-case you want to set that to zero for this rarely used connection. And to make that connection close ASAP you could set the connection idle time to zero minutes as well although I don’t know if and how much of a performance penalty this will give. Perhaps an idle time of 1 minute might be better.
Hope this helps.
ROCLASI:
Hi Gary,There is a difference between the definition of the connection pool and the actual open connections.
The moment you want to access objects from a connection Servoy will open a new connection when not available and close it again when idle.
But you can also set the maximum idle connections to stay open for re-use so you don’t have the overhead of opening the connection. I guess in your use-case you want to set that to zero for this rarely used connection. And to make that connection close ASAP you could set the connection idle time to zero minutes as well although I don’t know if and how much of a performance penalty this will give. Perhaps an idle time of 1 minute might be better.Hope this helps.
It does help but leads to another question. Setting this idle time is done globally for all solutions on the server, right? Or can it be done within a given solution?
Gary
Hi Gary,
Servoy uses a 3-tier architecture (client-server-database) so the connections are managed by the server. The clients/solutions have no built-in control over the connections at all so yes, it’s server-wide.
But perhaps Scott Butler’s DirectSQL plugin might do what you want. But it does look like it’s a client-side connection only at this point (i.e. 2-tier architecture) so the client has to be able to connect to the database server from where the client is running. But Scott might be able to give you more info on this.
Hope this helps.
ROCLASI:
Hi Gary,Servoy uses a 3-tier architecture (client-server-database) so the connections are managed by the server. The clients/solutions have no built-in control over the connections at all so yes, it’s server-wide.
But perhaps Scott Butler’s DirectSQL plugin might do what you want. But it does look like it’s a client-side connection only at this point (i.e. 2-tier architecture) so the client has to be able to connect to the database server from where the client is running. But Scott might be able to give you more info on this.
Hope this helps.
Thanks! I know Scott and will contact him. His folks actually developed one of the solutions on our server.
Gary