Inability in usage of session-pool (NebulaPool)

[aminmaghsodi]

As you see in all your examples, first you create a session pool with max-sessions=n, and then you pick just one Session to execute a command.

After your session creation, first, you execute "use space" and then you execute all your other commands by this Session object, the problem is that you cannot use session-pool correctly. why? because if you want to use it, per time you call session.release() it clears all states (it means it clears "use space") too. and in next time you should first call "use space; (and then your main command...)", and it increases the time of command execution (for example it increases INSERT time from 5 ms to 11 ms).

It looks like that it is better not to reset space declaration in release time and also it is helpfully to declare space name in CREATION phase of session-pool (take HostAddress, nebulaConfig, and space name)

[wey-gu]

@laura-ding , this seems to make sense, for the case(there indeed is such case) when we only make a few(i.e. one) queries, in a lifetime between session creation and release, the use foo_space's footprint/cost is big here.

Is it possible to consider add options(not the default behavior to keep backward compatibilities) to enable a different connection release policy(something like signout_in_release=False), rather than calling .signout(), it only set the .is_used flag instead.

This could be expensive for maintaining signed-in connections, while, if user is knowing what they are doing, it could be beneficial in certain case(as the above case) to save some ms on calling use foo_space.

What do you think, if it makes sense, I can prepare PR/proposal for it. Please correct me and @aminmaghsodi if something was misunderstood as well.

Thanks!
BR //Wey

[laura-ding]

@aminmaghsodi Thanks for your questions.
The release of the Session is in order to reuse the connection when the user may be idle for long periods of time. If the user business uses it frequently, then it is not necessary to take a session and release it every time. The user can keep the session and use it for subsequent operations.

[aminmaghsodi]

Thank you @laura-ding and @wey-gu

By your approach and not using realse then we just have a connection pool and user should manages damaged connections himself. I suggest using a wrapper as a connection-manager, which keeps healthy connections and their states (e.g. use space). and when a user says pool.getSession() it takes a free connection from a data-structure and just returns it, otherwise it requests to connection-pool to recreate a healthy connection. In current usage if a connection got damaged, user should understand it, release it and get another connection from pool, but if we had a layer to keep all created connections, it can also control and manage this damages. Is is it OK or we prefer each user should handle these damages himself?

[laura-ding]

@aminmaghsodi If the connection is broken, then the session will automatically release the connection and mark it as broken. Then the session will get a valid connection from the pool. The user doesn’t need to worry about connection disconnection exception handling. Sessions and pools ensure the reliability of the connection.

[aminmaghsodi]

Thanks for your responses @laura-ding,

So after this good discussion I understood that we don't have connection-manager in nebula-client and just have connection-pool which can't manage the live states of connections and doesn't have live monitor on them. so I considered to use nebula-pool for creating n connections. Then I created n threads and assign each session of nebula-pool to each thread without releasing session. Then on exception times I should handle the connection exception which releases the session and takes a new session from the pool.

Thanks.