: > Noble? Shalin? what's the point of throwing away a connection that's been
: > in use for more then 10 seconds?
: Hoss, as others have noted, DIH throws away connections which have been idle
: for more than the timeout value (10 seconds). The jdbc standard way of
: checking for a valid connec
On Sat, Sep 3, 2011 at 1:29 AM, Chris Hostetter wrote:
>
> : I am not sure if current version has this, but DIH used to reload
> : connections after some idle time
> :
> : if (currTime - connLastUsed > CONN_TIME_OUT) {
> : synchronized (this) {
> :
watch out, "running 10 hours" != "idling 10 seconds" and trying again.
Those are different cases.
It is not dropping *used* connections (good to know it works that
good, thanks for reporting!), just not reusing connections more than
10 seconds idle
On Fri, Sep 2, 2011 at 10:26 PM, Gora Mohanty
take care, "running 10 hours" != "idling 10 seconds" and trying again.
Those are different cases.
It is not dropping *used* connections (good to know it works that
good, thanks for reporting!), just not reusing connections more than
10 seconds idle
On Fri, Sep 2, 2011 at 10:26 PM, Gora Mohanty
On Sat, Sep 3, 2011 at 1:38 AM, Shawn Heisey wrote:
[...]
> I use DIH with MySQL. When things are going well, a full rebuild will leave
> connections open and active for over two hours. This is the case with
> 1.4.0, 1.4.1, 3.1.0, and 3.2.0. Due to some kind of problem on the database
> server,
On 9/2/2011 1:59 PM, Chris Hostetter wrote:
: I am not sure if current version has this, but DIH used to reload
: connections after some idle time
:
: if (currTime - connLastUsed> CONN_TIME_OUT) {
: synchronized (this) {
: Connection tmpConn =
: I am not sure if current version has this, but DIH used to reload
: connections after some idle time
:
: if (currTime - connLastUsed > CONN_TIME_OUT) {
: synchronized (this) {
: Connection tmpConn = factory.call();
:
I am not sure if current version has this, but DIH used to reload
connections after some idle time
if (currTime - connLastUsed > CONN_TIME_OUT) {
synchronized (this) {
Connection tmpConn = factory.call();
clos
: However, I tested this against a slower SQL Server and I saw
: dramatically worse results. Instead of re-using their database, each of
: the sub-entities is recreating a connection each time the query runs.
are you seeing any specific errors logged before these new connections are
created?
I have a data import handler that is importing data in full mode from SQL
Server. It has one main entity and three sub-entities. Against a good database,
it appears to open 4 connections total. One for the main query and the other 3
subqueries just re-use their connections. This works well enoug
10 matches
Mail list logo
