Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Mike Schrag <email@hidden>
- Date: Mon, 12 May 2008 16:09:27 -0400
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.
By "complications" I do mean optimistic locking ... Optimistic locking
is only half the problem. Optimistic locking addresses when I write
and I'm out of sync, but if you work on a collaborative app, the other
part of the problem is staying in sync in the first place so you don't
HAVE that problem (much). I agree you have to deal with the locking
failures, but for the apps we typically work on, at least, showing out
of date info is a problem. Using multiple stacks is the easier fix
for this because you're in-process, so signaling and locking is easier
to do. Using multiple instances with Wonder's remote syncing tries to
make it transparent, but it's just a hard problem. So, for me,
multistack/remotesync is all about user experience. It's not about
making our lives (as programmers) easier. One instance/one stack is
REALLY easy for us :)
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