Re: EOF Connection Pooling?
Re: EOF Connection Pooling?
- Subject: Re: EOF Connection Pooling?
- From: Chuck Hill <email@hidden>
- Date: Tue, 22 Nov 2005 10:10:47 -0800
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
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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