Closed felipenoris closed 5 years ago
When I use dpiPool_acquireConnection, the attribute pool in dpiConnCreateParams *params is ignored?
Yes. I've added a note in the documentation regarding this.
dpiConn_create does the same thing as dpiPool_acquireConnection if the attribute pool in dpiConnCreateParams *params has a reference to a Pool?
Yes. I've added a note in the documentation regarding this.
What is a session ? The docs describe a Pool to be a session pool, but dpiPoolCreateParams.minSessions defines the number of sessions (connections? different users in non-homogeneous sessions?) for a single pool.
Sessions and connections are effectively the same. Each time you acquire a connection from the pool you get a brand new object -- even if the "session" that is attached to that connection is the same one you checked out previously. As such I agree that it can be a bit confusing to differentiate between "sessions" and "connections". If you understand them to be virtually identical (just that the pool owns "sessions" which are virtual "connections" which you can transform into "real" connections by acquiring them) I think you can't go too far wrong. @cjbj and I were talking about this last week. Perhaps it might be wise to come up with a good definition of the distinction and publish that -- and be consistent in the documentation when referring to a "session" and a "connection" -- or simply eliminate the distinction altogether!
In the dpiPool_acquireConnection docs, it says: Acquires a connection from the pool and returns a reference to it. This reference should be released as soon as it is no longer needed. The release of a connection reference should be done by calling dpiConn_close() or dpiConn_release(), right?
What it means is that you should call dpiConn_release(). Calling dpiConn_close() frees up the server resources but a reference is still retained. If you forget to call dpiConn_release() then the memory ODPI-C allocates internally for the connection will be retained permanently and you will experience a memory leak. I've clarified that in the documentation.
@anthony-tuininga thanks again for answering and improving the docs!
Just one comment on the last question: I understand that one must call dpiConn_release
to prevent memory leak. But what I missed in the docs was how to put a session/connection back into the pool. And after a few tests, it looks like I just have to call dpiConn_close
on the connection. Even if it's not yet released, just by closing it I'm able to acquire a new session/connection from the pool.
Cheers!
You're welcome. And thanks for asking questions! Without those questions I would simply assume that the documentation is perfectly clear and contains all of the information you need. :-) I've added a further note to the documentation of dpiPool_acquireConnection() that a call to dpiConn_close() will release the connection back to the pool.
In
dpiPool_acquireConnection
, the input parameter*pool
is described as:Also,
dpiPool_acquireConnection
expects a parameterdpiConnCreateParams *params
, which has a fieldpool
described as:Aparently,
dpiConn_create
also has capability to create a connection from a pool, as described in the docs:Questions
When I use
dpiPool_acquireConnection
, the attributepool
indpiConnCreateParams *params
is ignored?dpiConn_create
does the same thing asdpiPool_acquireConnection
if the attributepool
indpiConnCreateParams *params
has a reference to a Pool?What is a session ? The docs describe a Pool to be a session pool, but
dpiPoolCreateParams.minSessions
defines the number of sessions (connections? different users in non-homogeneous sessions?) for a single pool.In the
dpiPool_acquireConnection
docs, it says:Acquires a connection from the pool and returns a reference to it. This reference should be released as soon as it is no longer needed.
The release of a connection reference should be done by callingdpiConn_close()
ordpiConn_release()
, right?Thanks in advance!