on 1/17/00 10:34 AM, Scott Tavares <[EMAIL PROTECTED]> wrote:
> It has always been my vision to keep OPaL as independent as possible.
Why?
I think that when you are working with commercial closed source software (or
software with a GPL license), this was an issue, but with Turbine, I don't
see what the big issue is. You might as well make use of as much of the code
as possible. That is the point of turbine, MFC style code re-use.
Please explain your comment.
> 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.
Fine, then abstract out the opl.database.Db* stuff from opl as well. Do you
see my point? Why not make a generic "bridge" that can work with any other
DB pooling framework that also is not dependant on opl (through package
naming)?
> 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.
You are correct. So far, having two pools hasn't shown to be that big of a
waste of resources and isn't that big of a deal.
> 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?
That is a bad way to do it imho. One should always release connections in a
finally so that you *know when* they are being released. Otherwise, you are
stuck waiting for the GC to clean up your mess. I can see a nice DoS attack
just waiting to happen.
> 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.
BINGO!
> 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.
>From a marketing standpoint, I would like to move away from having to make
developers download a bazillion different packages to get what they want. I
think that OPaL fits nicely into the Turbine model and would like to see it
sit there. I'm ok if you don't want to integrate it more with Turbine, but I
think that is also bad. I'm -0 on that.
-jon
--
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
