Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Mike Schrag <email@hidden>
- Date: Mon, 12 May 2008 13:11:06 -0400
Can any one advise me what is the difference between :
* Deploying Multiple Instances of a WebObjects application from
deploying a WebObjects application with Connection pooling
configured.
i.e., I have a WebObjects app, now I will deploy this app with 5
instances (or) I configure my WOApp with Connection pooling having
max 5 connections and deploy it.
They will behave differently. They will scale differently in
response to loads, depending on what your app does. Deploying
multiple instances is the normal way to go. Personally, I would
only use connection pooling in combination with multiple instances.
Chuck and I disagree here :) This is entirely presuming you're using
Wonder:
If you turn on multiple EOF stacks in Wonder, you get most of the
benefit of being in a single stack, but without having to deal with
all the complications of being in multiple instances. In most WO
apps, scaling problems are due to the single EOF lock. Multiple
stacks alleviates this to a large extent, and for me would be my first
choice for the _scaling_ aspect. There are, of course, border cases
where you have to be careful -- Miguel recently ran into this, for
instance, where if you are using Wonder's eof stack synchronization,
it will synchronize the snapshots of inserts into each stack, but if
you're inserting a lot of "write-only" data, you can leak snapshots
(because they insert with a refcount = 0). But there are some new
API's to control this if this presents a problem. For your "average"
WO app, this should basically just work (barring being really nervous
like Miguel :) ).
Where multiple instances is really a win is 1) if you DO have a
problem in your app instance, you don't bring down the entire app. So
multiple instances gives you VM isolation (like an OutOfMemoryError,
for instance). 2) If you want fault tolerance, you should be deploying
on multiple machines, in which case you would have to use multiple
instances to take advantage of that.
Now, Wonder also provides remote EOF synchronization across multiple
instances (which behaves SIMILARLY to stack synchronization), but it
does come at a cost -- increased complexity, for one (even though it's
only a couple configuration Properties, it increases "the things that
can go wrong" quotient) and also it increases network traffic between
your boxes (by default it uses multicast notifications between your
instances to track changes).
So anyway, if you're having scaling problems and you want the fastest
way to a solution with the least amount of trouble, adding stacks is
probably it. If you want fault tolerance on top of that, then
multiple instances is the way to go.
ms
_______________________________________________
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