• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Connection pooling + WebObjects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Connection pooling + WebObjects


  • Subject: Re: Connection pooling + WebObjects
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 12 May 2008 10:51:49 -0700


On May 12, 2008, at 10:11 AM, Mike Schrag wrote:

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:


I think it can be a bit more complex...


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.

But you can also really increase the memory footprint. This entirely depends on what is happening in your application. If your users primarily only work data specific to them, then you should not notice too much of a difference. If your users work on shared, large data sets then the JVM memory needs are going to increase. This is not an argument for multiple instances, but it is something to be aware of as it reduces the number of instances you can run on one machine.


It also very much depends on if your apps have EOF as the bottleneck, or if some other processing is the bottleneck. If EOF is not the bottleneck (and it is for most of us), then multiple instances is the only thing that will help.

I am not sure what you mean by "the complications of being in multiple instances". Stack / instance synchronization or not, you still have to handle optimistic locking errors. You have to handle them less frequently if you are synchronizing, but they still have to be handles (or ignored because they happen less frequently if you so choose...).

One thing that gives me pause with respect to multiple, synchronized stacks is that is an an added layer of complexity on top of the already complex concurrency issues. While I trust that you (Mike) have soundly tested this, it adds complexity for a reduction in the frequency of needing to handle something that I must handle anyway. It seems to me that multiple instances are simpler in this respect. It also adds processing overhead for every possible case of an optimistic locking conflict, not just the ones that actually matter. I don't have a clear idea on how that affects the balance of this equation.


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.


Yes, if you are having scaling _problems_, I try out multiple stacks and study how the affect your app. If you are simply planning a deployment infrastructure, go for multiple instances first.

Chuck

--

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


  • Follow-Ups:
    • Re: Connection pooling + WebObjects
      • From: Mike Schrag <email@hidden>
References: 
 >Connection pooling + WebObjects (From: "Shravan Kumar.M" <email@hidden>)
 >Re: Connection pooling + WebObjects (From: Kieran Kelleher <email@hidden>)
 >Re: Connection pooling + WebObjects (From: "Shravan Kumar.M" <email@hidden>)
 >Re: Connection pooling + WebObjects (From: Chuck Hill <email@hidden>)
 >Re: Connection pooling + WebObjects (From: Mike Schrag <email@hidden>)

  • Prev by Date: Re: [OT] Frontbase Export/Dump
  • Next by Date: Re: [OT] Frontbase Export/Dump
  • Previous by thread: Re: Connection pooling + WebObjects
  • Next by thread: Re: Connection pooling + WebObjects
  • Index(es):
    • Date
    • Thread