Re: [Webware-discuss] Database Connection Pool Storage

[Uwe G. <mai...@on...>]

jk...@de... wrote:

>Personally I wouldn't put anything application specific in the superclass
>because the superclass is where you define the general solution and
>subclasses is where you define the specific solution.
>
>Having said that, you can really break your question into two possible
>solutions that I personally could live with:
>
>1) you could live with the resource management methods provided by the
>webware servlet architecture (init(), sleep(), and awake() for example)
>
>  
>
Do you mean, everytime a user requests something from a servlet, i
should create
a new dbconection in awake() and at sleep() time i close the connection?

>2) or you could engineer your own db connection pool and use that via
>containment in your servlets.
>  
>
Of cause, this is what i wanted to do.

>In the architecture my team has built around webware we abstract all our
>business logic out of the servlets themselves into a system of contained
>classes that know how to manage what they need to get the job done.  I
>also am lucky in that I have someone here to rely on to provide
>application data layer access via some agreed upon apis and in most cases
>she's provided me with an abstraction of my database objects that
>effectively hides the db connections from me entirely.   This simplifies
>the business logic extensively, allowing it to be focused upon higher
>level decisions and logic.
>  
>
Be glad. You don't have to think about it.
Please ask this someone how he/she did it.
(e.g. Where are the db-connections stored? Same thread as the servlet?)

>The advantages of this are that I actually have a very small number of
>servlets that are all built around the core ability to identify what is
>being asked, find an object that can do that thing and marshalling that
>object to do the thing for it.  The details of how it does that thing are
>lost on the servlet.
>
>I guess what I'm saying is that I'd find a way to bury db connection
>pooling in the depths of your own architecture rather than relying on
>webware to manage it for you.  But there's probably lots of arguments for
>doing the first option too.
>
>geeze, looking back up on my text here, I hope this helps in some way.
>jeremy
>
>
>  
>
Interesting, but i'm still clueless.
Anyway, thanks for your explanation.

Uwe

>>Uwe Grauer wrote:
>>
>>    
>>
>>>Hi Experts,
>>>
>>>      
>>>
<snip - look at the previous mails \snip>