Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Mike Schrag <email@hidden>
- Date: Mon, 12 May 2008 16:16:04 -0400
I use connection pooling (together with multiple instances) mainly
to avoid problems in the way EOF works (as in, locking everything).
Optimistic locking in EOF is, IMO, broken by design (<http://terminalapp.net/dr-optimistic-locking/
>), so I have to run some critical parts of my code with the entire
EOF stack locked. That means during that processing, no user of that
instance will be able to do whatever he tries to that needs EOF
access. So, connection pooling will help, because if you have N
connections, instead of locking all your users of that instance, you
lock an average of all the users / N.
For the vast majority of apps, I don't believe people will notice the
brokenness, but I do agree that it is broken. The fix, unfortunately
may be worse than the brokenness.
Note that connection pooling should be used with resource usage in
mind. Not only memory for the snapshots, but you'll also consume
database connections. That may force you to reconfigure your
database server, or, in some cases like PostgreSQL, you may even be
forced to change some low level kernel configuration values to
handle all the shared semaphores PostgreSQL needs to handle all the
simultaneous connections. This is even more serious if you connect
to more that one DB on your app. If you connect to two different
databases running on the same server, and create a pool of 5
connections, a single instance of the application will be using 10
connections.
Sure, but this is how the entire rest of the world operates. Go tell
any other server developer that you have a single database connection
and they'll laugh at you. Having to configure my kernel to eek out the
most performance I can is a problem I would like to have ... Waiting
for EOF to unlock my entire stack is not :)
EOF and WO have some really great features. Awesome EOF performance
characteristics is, unfortunately, not really one of them. Again,
though, for most apps, it doesn't really matter. But when you want to
push it, it's something you have to be considering. This is why I
don't laugh at Twitter having problems with Rails. You go make an app
that handles 11,000 requests per second and come back and talk to me
about how awesome your framework is. Scaling is hard, and I don't
care what framework you develop in, you're going to sell your
beautifully-designed-api-soul to make it scale.
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