----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Sunday, January 16, 2000 10:27 PM
Subject: Re: OPaL init in Turbine.doGet() and more
<snip>
> > 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.
It has always been my vision to keep OPaL as independent as possible. I
think keeping the opl.database.DbBroker interface serves this issue. This
way if someone does not want to use the default opl.database.DbBrokerImpl
bridge to turbine.util.db.DBBroker they have the option to write their own
bridge to any other DB Pooling framework they want by just registering their
bridge with opl.database.DbBrokerManager.
jon, i have looked at the DBWeblogic example. Now correct me if i'm wrong
(which happens allot i'm afriad to say), but the only difference from this
db driver and the others is the url. from what i can see, in the case of
DBWeblogic this url is to the Weblogic server which manages its own
connection pooling which in turn, if true, will amount to the use of _two_
pooling mechanisms simultaneously, Turbine's and Weblogic's.
<snip>
> > 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.
in other words... the way you had it originally? So that, for example in the
retrieveObject() method of PersistenceBroker, if an exception is thrown and
the dbConn.free() method never gets called, the connection will still get
released when the instance of DbConnection gets garbage collected?
>
> 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.
>
"...move most of the database functions from the persistence broker to db
connection..." do you mean the process methods and retrive, save and delete
methods? so the developer will make calls like this:
PersistenceBroker.getInstance().getConnection(classMap.getBrokerName()).retr
ieveObject(poVisitor);
in stead of this:
PersistenceBroker.getInstance().retrieveObject(poVisitor);
my only issue with all of this is that it allows, as Jon noted, open
connections to remain open and relies on garbage collection to release them
whereas with the finally blocks the connections are released explicitly
right when they are no longer needed.
>
> 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?
>
Well the only reason i added it there is for convenience, there is no reason
i can not just ues a independent local copy of Turbine to do this.
Therefore, if this is the direction we are going to go, i have to ask the
queston; should OPaL even be in the turbine source tree at all or should it
be moved to its own project? The last time i asked this question, jon* (as i
recall, and could be wrong again) agreeded it should be but wanted to let it
"mature" under Turbine first. Maybe this would be a good time to re-examin
this issue.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
