Scott, 
I've really didn't want make any comments on your and
jon's discussion of Turbine, because my comments are
critical and I don't have time to back them up with
contributions. But your latest changes to the
persistence broker are not good.

--- jon * <[EMAIL PROTECTED]> wrote:
> on 1/13/00 12:12 PM, Scott Tavares
> <[EMAIL PROTECTED]> wrote:
> 
> 
> > i agree with you on this. the design came as a
> compromise. George had come
> > across a GPLed connection db pooling object set
> and wanted to incorporate it
> > directly into OPaL. This prompted you to -1 it
> because of the GPL part and
> > you and i said that the org.apache.turbine.db.*
> stuff would be the better
> > choice. George then came up with the idea of using
> an interface so that one
> > could use any db pooling framework as long as it
> implemented the interface.
> > i took that a step further and said lets make the
> default db broker a
> > wrapped version of the
> org.apache.turbine.db.DBBroker and have it
> controlled
> > through the TurbineResources.properties file.
> 
This is't true.  The original design used the broker
manager.  I  only implemented Marc Minch's but removed
it from cvs because of the gpl concerns. 

> nope. this is wrong and a complete duplicate of
> effort. there is no reason
> why you can't already use the existing database
> connection pooling code as a
> wrapper around another pool. look at the weblogic
> example that comes with it
> in org.apache.turbine.util.db. It is a wrapper
> around weblogic's pooling
> scheme. this works fine. you can plug whatever
> pooling code into it.
> 
> there is no reason to have connection brokering as
> part of OPaL. it is out
> of the scope of that package and the class names
> being duplicated for what
> is in org.apache.turbine.util.db just adds
> confusion.
> 
Jon, I don't agree with this.  The major reason for
the confusion is that you have OPL as an appendage of
Turbine.  Definitely, this isn't to the benefit of a
wider audience of OPL users.  No, you don't need to
superglue OPL to turbine.  The difficulty in using
Turbine's connection pooling with the broker manager
is mostly to do with problems in the design of
Turbine's broker manager.  It's a broker manager,
dbconnection, and pooling code all wrapped together. 
This really makes it unusable for other projects like
OPL.  You might want to rethink that design.  For
example, you use information like the timestamp in the
dbconnection class to control the connection pooling. 
This is patently wrong.  Any other connection broker
gives you a jdbc connection.  All of the information
for managing the connection should be internal to the
broker.  Not handed to the user.

> what i what you to look at is the fact that the
> release of the connection is
> in a finally statement so that there is no chance
> that it will be left open.
> the current scheme in OPaL allows that chance to
> happen and that is bad.
> 
There are better ways of dealing with this. 
Definitely, many of the fuctions in the persistence
broker should be moved to the db connection class. 
Then exceptions can be handled when they percolate up
to the user.  I believe it's probably best for
dbconnection to hold a reference to the broker so it
can return itself to the broker in a finalize if the
user fails  to return it. 

So, Scott, my advise is roll back your pesistence
broker changes, move  most of the database functions
from the persistence broker to db connection, make the
broker a member of dbconnection so dbconnection can
return itself to the broker in a finalize if the user
doesn't properly handle the exception.  Probably, all
the dbconnection problems should throw a specific
exception.

Most importantly, please try to get an example working
so you can test the validity of your thoughts.  

At this point, you probably shouldn't pollute the
other turbine code with opl junk.  Your most recent
changes required opl to be compiled with the
distribution of turbine.  Why couldn't you work with
your own copy?  What was the benefit of adding this to
Turbine.java?

- george

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to