Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25552 > unrolled thread

Re: The easiest framework for Java Database applications development released for production use

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The easiest framework for Java Database applications development released for production use Wojtek <nowhere@a.com> - 2011-02-07 20:51 -0800
    Re: The easiest framework for Java Database applications development released for production use Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-02-08 20:01 -0400
    Re: The easiest framework for Java Database applications development released for production use Arne Vajhøj <arne@vajhoej.dk> - 2011-02-08 19:08 -0500
    Re: The easiest framework for Java Database applications development released for production use Lew <noone@lewscanon.com> - 2011-02-09 07:55 -0500
    Re: The easiest framework for Java Database applications development released for production use yaormaAdmin <yaorma@gmail.com> - 2011-02-08 05:44 -0800
    Re: The easiest framework for Java Database applications development released for production use Arne Vajhøj <arne@vajhoej.dk> - 2011-02-08 19:06 -0500
      Re: The easiest framework for Java Database applications development released for production use Wojtek <nowhere@a.com> - 2011-02-08 21:59 -0800

#25552 — Re: The easiest framework for Java Database applications development released for production use

yaormaAdmin wrote :
> Often in large projects someone, somewhere, inevitably forgets to
> close the Statement and/or the Resultset in a finally block where an
> exception is thrown.  This results in a cursor being left open in the
> database.  Eventually the code is executed enough times to exhaust the
> maximum number of cursors allowed for the connection.  The next call
> that opens a cursor in the database fails.  This is often not the
> offending code but some perfectly good code that exists in some other
> far off place in the code.

Or you could just use a connection pool manager such as proxool. Use 
proxool to log into the database and then it manages all of that. DB 
connections which are idle for a given number of milliseconds are 
automatically closed. So all of the extra coding to fit yet another 
framework is not needed

Plus you get far better DB performance under load as you do not need 
the expensive connection establishment for every DB operation.

-- 
Wojtek :-)

[toc] | [next] | [standalone]

#25700

On 11-02-08 09:44 AM, yaormaAdmin wrote:
[ SNIP ]

> Thanks for the comments Wojtek.  In the example code the connection is
> instantiated using the DriverManager just to make the example simpler
> (and so it stands on its own, without needing additional
> dependencies).  The Yaorma framework has been used in several
> applications using pooled connections.  Most of this work has used
> Tomcat and would only run inside some sort of container.  I'll look
> into Proxool more, thanks for the tip.  What would you consider the
> gold standard for a connection pool for a desktop/rich client (Swing,
> RCP, etc.) application?
>
> Thanks again,
> John

I dunno about "gold standards", but C3PO is a much-used connection 
pooling library.

AHS
-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

[toc] | [prev] | [next] | [standalone]

#25854

On 08-02-2011 08:44, yaormaAdmin wrote:
> Thanks for the comments Wojtek.  In the example code the connection is
> instantiated using the DriverManager just to make the example simpler
> (and so it stands on its own, without needing additional
> dependencies).  The Yaorma framework has been used in several
> applications using pooled connections.  Most of this work has used
> Tomcat and would only run inside some sort of container.  I'll look
> into Proxool more, thanks for the tip.  What would you consider the
> gold standard for a connection pool for a desktop/rich client (Swing,
> RCP, etc.) application?

Desktop apps does not always need connection pools - I may even say
that they rarely need it.

http://commons.apache.org/dbcp/ is good database connection pool.

Arne

[toc] | [prev] | [next] | [standalone]

#25898

Arne Vajhøj wrote :
>> It is good advice to use a connection pool.
>>
>> But if you don't close the connections then they
>> are not returned to the pool and the pool will run
>> out of connections very quickly.

Wojtek wrote:
> proxool auto-closes idle connections

After how long?  This is no refutation of Arne's point.

Pretty much every pooling library supports the auto-close of idle connections, 
e.g., DBCP does.  Since all the major ones do, there's no reason to use a 
pooler that lacks the feature.

The default for DBCP is to allow five minutes before calling a connection 
"abandoned".

Under heavy load, abandoned connections can be a problem,  During that five 
minutes (or whatever), a lot of connections can be rejected if all the pool's 
connections are in use or abandoned but not yet auto-closed.  So Arne's advice 
is correct, even in the face of auto-close being enabled.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [next] | [standalone]

#25992

On Feb 7, 11:51 pm, Wojtek <nowh...@a.com> wrote:
> yaormaAdmin wrote :
>
> > Often in large projects someone, somewhere, inevitably forgets to
> > close the Statement and/or the Resultset in a finally block where an
> > exception is thrown.  This results in a cursor being left open in the
> > database.  Eventually the code is executed enough times to exhaust the
> > maximum number of cursors allowed for the connection.  The next call
> > that opens a cursor in the database fails.  This is often not the
> > offending code but some perfectly good code that exists in some other
> > far off place in the code.
>
> Or you could just use a connection pool manager such as proxool. Use
> proxool to log into the database and then it manages all of that. DB
> connections which are idle for a given number of milliseconds are
> automatically closed. So all of the extra coding to fit yet another
> framework is not needed
>
> Plus you get far better DB performance under load as you do not need
> the expensive connection establishment for every DB operation.
>
> --
> Wojtek :-)

Thanks for the comments Wojtek.  In the example code the connection is
instantiated using the DriverManager just to make the example simpler
(and so it stands on its own, without needing additional
dependencies).  The Yaorma framework has been used in several
applications using pooled connections.  Most of this work has used
Tomcat and would only run inside some sort of container.  I'll look
into Proxool more, thanks for the tip.  What would you consider the
gold standard for a connection pool for a desktop/rich client (Swing,
RCP, etc.) application?

Thanks again,
John

[toc] | [prev] | [next] | [standalone]

#26076

On 07-02-2011 23:51, Wojtek wrote:
> yaormaAdmin wrote :
>> Often in large projects someone, somewhere, inevitably forgets to
>> close the Statement and/or the Resultset in a finally block where an
>> exception is thrown. This results in a cursor being left open in the
>> database. Eventually the code is executed enough times to exhaust the
>> maximum number of cursors allowed for the connection. The next call
>> that opens a cursor in the database fails. This is often not the
>> offending code but some perfectly good code that exists in some other
>> far off place in the code.
>
> Or you could just use a connection pool manager such as proxool. Use
> proxool to log into the database and then it manages all of that. DB
> connections which are idle for a given number of milliseconds are
> automatically closed. So all of the extra coding to fit yet another
> framework is not needed
>
> Plus you get far better DB performance under load as you do not need the
> expensive connection establishment for every DB operation.

It is good advice to use a connection pool.

But if you don't close the connections then they
are not returned to the pool and the pool will run
out of connections very quickly.

Arne

[toc] | [prev] | [next] | [standalone]

#26221

Arne Vajhøj wrote :
> On 07-02-2011 23:51, Wojtek wrote:
>> yaormaAdmin wrote :
>>> Often in large projects someone, somewhere, inevitably forgets to
>>> close the Statement and/or the Resultset in a finally block where an
>>> exception is thrown. This results in a cursor being left open in the
>>> database. Eventually the code is executed enough times to exhaust the
>>> maximum number of cursors allowed for the connection. The next call
>>> that opens a cursor in the database fails. This is often not the
>>> offending code but some perfectly good code that exists in some other
>>> far off place in the code.
>>
>> Or you could just use a connection pool manager such as proxool. Use
>> proxool to log into the database and then it manages all of that. DB
>> connections which are idle for a given number of milliseconds are
>> automatically closed. So all of the extra coding to fit yet another
>> framework is not needed
>>
>> Plus you get far better DB performance under load as you do not need the
>> expensive connection establishment for every DB operation.
>
> It is good advice to use a connection pool.
>
> But if you don't close the connections then they
> are not returned to the pool and the pool will run
> out of connections very quickly.

proxool auto-closes idle connections

-- 
Wojtek :-)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web