--- jon * <[EMAIL PROTECTED]> wrote:
> on 1/17/00 10:34 AM, Scott Tavares
> <[EMAIL PROTECTED]> wrote:
> > 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)?
Actually, it's that way. The broker manager is a
generic bridge. You can implement any pooling scheme
you want as long as your broker satifies the
interface.
> > 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.
>
Move the db stuff from persistence broker to
dbconnection, and let it percolate up. Then, you
don't need the catch/finally junk.
>
> 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.
>
It's actually bad marketing to keep it in turbine.
Who can see it there? After all the work I did, I've
gotten close to zero feedback. Probably, it would
help tremendously to have a working sample.
In an earlier mail, I gave Scott a db class and a
hand-coded class map. Only thing missing is the
pooling code. Marc Minch would let apache use his.
jon, hope your not feeling too much heat but the
design of the turbine stuff doesn't work for the
broker interface. I think this is a flaw in turbine,
not vice versa.
- 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]
