>
> 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)?
>
yes i do get your point, how fine grain do we partition every thing?
correct? well, i feel that we need to keep some of reasonable ballance on
how this happends. i still think the use of the interface and a bridge impl.
to Turbine pooling classes as a default is a resonable ballance between a
tight coupling to turbine or a compleatey external bridge... just my $0.02.
Does anyone else on this list have an opinion on this? do _not_ be afraid to
speek up even if you are not a committer. its your input that keeps all of
this going.
> > 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.
>
hey... i got something correct... ;-) this makes my day. Anyway, i guess i
don't have any other opinion in the context of this example. if it works and
the people that are using it are happy with it then great...
>
> > 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!
>
hey... two correct issues in one day ;-)
>
> 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.
>
well now that i think about it, maybe it is still too early to think about
this. there is still allot of work that needs to be done on OPaL. i think
for now we should leave to where it is but, this is all the more reason to
keep the opl.database.DbBroker interface. If for some reason there is a big
enough demand for OPaL to become its own entity, it will be easier to
dissect it out of Turbine. This puts me at -0 also.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
