Connection pool settings in Uby API

[judithek]

The connection pool settings in the Uby API seem to be a bit strange:

        p.setProperty("hibernate.c3p0.min_size","1");
        p.setProperty("hibernate.c3p0.max_size","1");
        p.setProperty("hibernate.c3p0.timeout","0");
        p.setProperty("hibernate.c3p0.max_statements","0");
        p.setProperty("hibernate.c3p0.idle_test_period","5");

If I read this correctly, that means:

- there is at most one active connection (bad if Uby is used in a multi-threaded situation)
- that connection is never closed even if unused (timeout = 0)
- no queries are cached (max_statements = 0)

I would suggest different default settings:

        p.setProperty("hibernate.c3p0.min_size","4");
        p.setProperty("hibernate.c3p0.max_size","10");
        p.setProperty("hibernate.c3p0.timeout","300");
        p.setProperty("hibernate.c3p0.max_statements","10");
        p.setProperty("hibernate.c3p0.idle_test_period","5");

Which I would read as:
- keep a couple of connections around (min_size = 4) and drop if if unused for too
long (timeout = 300)
- if there are multiple threads using the API, allow max 10 parallel connections

Not sure about the caching (max_statements) though. 

Does that make sense?

In any case, it would be nice if such things would not be configured internally by
the API because in different deployment scenarios (experimental setup, webapplication,
etc.) different settings would make more sense. Hence, having a Uby constructor that
accepts an externally created sessionfactory or even a session might be useful - although
that might be worth a separate issue.

Original issue reported on code.google.com by richard.eckart on 2014-06-25 15:43:42

[judithek]

I was about to test settings that are very similar to your suggestion - min_size and
max_size are both set to 10, however.

Now I am currently testing the settings you suggested (with the Web UI)

>>In any case, it would be nice if such things would not be configured internally by
the API because in different deployment scenarios (experimental setup, webapplication,
etc.) different settings would make more sense. Hence, having a Uby constructor that
accepts an externally created sessionfactory or even a session might be useful - although
that might be worth a separate issue.

agree

Original issue reported on code.google.com by eckle.kohler on 2014-06-25 18:15:18

• Labels added: Milestone-0.6.0

[judithek]

these settings did not solve the broken pipe problem in the Web UI:

        p.setProperty("hibernate.c3p0.min_size","4");
        p.setProperty("hibernate.c3p0.max_size","10");
        p.setProperty("hibernate.c3p0.timeout","300");
        p.setProperty("hibernate.c3p0.max_statements","10");
        p.setProperty("hibernate.c3p0.idle_test_period","5");

will try my other hypothesis therefore (currently, no proper transaction management
for Uby queries)

Original issue reported on code.google.com by eckle.kohler on 2014-06-26 06:37:15

[judithek]

Hm. I could imagine that the the Uby API checks out *one* connection from the pool when
the session is created and then never returns it because it keeps holding on to the
session forever. In such a case, it would always display the symptom independently
from the pool settings. A remedy would be to instantiate the Uby API during each web
request and then throw it away again (mind that in a web-app, the request is the natural
scope for a db session). This would currently result in some overhead though, because
upon creation, the Uby API tries to set up all kinds of indexes - a task that is only
required once.

Original issue reported on code.google.com by richard.eckart on 2014-06-26 06:50:13

[judithek]

(No text was entered with this change)

Original issue reported on code.google.com by eckle.kohler on 2014-10-09 17:25:36

[judithek]

(No text was entered with this change)

Original issue reported on code.google.com by eckle.kohler on 2014-10-30 16:20:59