Re: EOF Connection Pooling?
Re: EOF Connection Pooling?
- Subject: Re: EOF Connection Pooling?
- From: Dov Rosenberg <email@hidden>
- Date: Tue, 22 Nov 2005 13:34:56 -0500
- Thread-topic: EOF Connection Pooling?
We use Jrun on our production servers because it has the ability to run
multiple web apps within the same JVM. That gives us the multi db
connections for multiple customers. When you want to run the same app on the
same box, you need to have multiple servlet instances. We have run multiple
Tomcat instances on a box without any problems. It just seems a lot heavier
weight approach than how Jrun does it.
Dov Rosenberg
On 11/22/05 1:10 PM, "Chuck Hill" <email@hidden> wrote:
> Hi Dov,
>
> On Nov 22, 2005, at 7:15 AM, Dov Rosenberg wrote:
>
>> Is there any way to convince EOF to use a database connection pool?
>> I noticed that there appears to be some JNDI lookup for a
>> datasource but I could not get it to use a Tomcat connection pool.
>> It looks like there needs to be something set up in the EOModel but
>> could not come up with the correct combination of chicken blood and
>> ritual sacrifice to get it to work properly.
>>
>> My primary motivation is that our apps are deployed as servlets
>> which makes it harder to run multiple instances of an app in the
>> same container like JavaMonitor enables when you run as a regular
>> WO application.
>
> That has always been my major concern with deploying like that. The
> ability to run multiple instances is crucial (IMHO) to scalability.
> Since EOF is single threaded, and the locks on the EOF stack last
> much longer than the DB transaction, multiple instances/stacks are
> needed to ensure efficient DB access.
>
>
>> The only way we can get multiple db connections seems to start
>> multiple instances on different machines or run multiple servlet
>> containers on the same box.
>>
> I am not familiar with the downside of running multiple servlet
> containers on the same box. Can you comment on this?
>
>
>> I saw some references to EOF and multiple connection stacks that
>> looked promising but very complex. Has anyone done this, if so are
>> there any rules that we should follow.
>>
> I have done this occasionally. It can eat up lots of memory so for
> most situations you don't want one per user. You will need to
> control their creation, pool the stacks and share them across
> sessions so that they don't cause OutOfMemory problems. There are
> also some changes to how the EOF classes work that are perhaps not
> immediately obvious - see the next point.
>
>> We have 2 apps. One is a regular WO app deployed as a servlet the
>> other is a little different. It uses a sharededitingcontext for
>> performance caching. We may be changing that in the future, but I
>> am a little concerned with dealing with multiple EOF stacks while
>> using a SharedEditingContext
>
> You are correct to be concerned. What is often called "the shared
> editing context" is in fact, the defaultSharedEditingContext. This
> is the shared editing context for the default EOF stack. Once you
> start creating your own stacks you also have to create a shared EC
> for each and use it for all editing contexts attached to that stack.
> This also applies to a couple of other things IIRC, though I don't
> recall what at the moment. Perhaps the defaultModelGroup?
>
> Chuck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden