RE: Persistence Broker best practices

[Bonnie MacKellar <BM...@mobius.com>]

OK, thanks. That was exactly what I was wondering,
whether you really meant "close" or just "release".
This makes more sense.

Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
bmackell@mobius.com


> -----Original Message-----
> From: Thomas Mahler [mailto:thma32@web.de]
> Sent: Friday, May 02, 2003 3:30 AM
> To: OJB Users List
> Subject: Re: PersistenceBroker best practices
> 
> 
> Hi again,
> 
> Bonnie MacKellar wrote:
> > I have a question about your answer :
> > 
> > When you say that broker.close() will close all resources, 
> do  you mean
> > that the JDBC connections are actually closed? Or just 
> returned to the
> > connection pool? 
> 
> "close" was not precise. I should have said "release".
> 
> JDBC connections are always released with a connection.close().
> If you are using connection pooling this close() call does 
> not close the 
> connection, but returns it to the pool only.
> By default OJB uses connection pooling. But you can specify different 
> behaviour in OJB.properties:
> 
> #-------------------------------------------------------------
> ---------------------------
> # ConnectionFactory / Default ConnectionPool
> #-------------------------------------------------------------
> ---------------------------
> # The ConnectionFactoryClass entry determines which kind of 
> ConnectionFactory
> # is to be used within org.apache.ojb as connection factory.
> # A ConnectionFactory is responsible for creating
> # JDBC Connections. Current version ships four implementations:
> #
> # 1. ConnectionFactoryNotPooledImpl
> #    No pooling, no playing around.
> #    Every connection request returns a new connection,
> #    every connection release close the connection.
> # 2. ConnectionFactoryPooledImpl
> #    This implementation supports connection pooling.
> # 3. ConnectionFactoryDBCPImpl
> #    Using the jakarta-DBCP api for connection management, support
> #    connection- and prepared statement-pooling, abandoned connection 
> handling.
> # 4. ConnectionFactoryManagedImpl
> #    Connection factory for use within managed environments - 
> e.g. JBoss.
> #    Every obtained DataSource was wrapped within OJB (and ignore
> #    e.g. con.commit() calls within OJB).
> #    Use this implementation e.g if you use Datasources from an 
> application server.
> #
> 
> > If they are physically closed, how does that affect your
> > advice below
> > to return brokers as quickly as possible to the pool? 
> Wouldn't that be a
> > problem if connections are constantly being opened and closed? 
> 
> Sure! That's why we use connection pooling by default.
> 
> chers,
> Thomas
> 
> > thanks,
> > Bonnie MacKellar
> > software engineer
> > Mobius Management Systems, Inc.
> > bmackell@mobius.com
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Thomas Mahler [mailto:thma32@web.de]
> >>Sent: Thursday, May 01, 2003 1:23 PM
> > 
> > 
> >>Yes! broker.close() will close all resources (e.g. JDBC 
> connections) 
> >>used by that broker and return the instance to the pool.
> >>
> >>be careful not to use closed broker instances.
> >>
> >>The usually best thing is to use brokers as short as 
> possible and to 
> >>return them asap back to the pool. This will help to scale 
> >>your application.
> >>If you have a fixed number of threads it's also ok to use one 
> >>dedicated 
> >>broker per thread.
> >>
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>