On 6 Dec 2010, at 14:20, Simon wrote:
i was thinking the same - alternatively:
- do whatever is you are doing in a background thread
- switch on concurrent request handling, as i presume that it is
actually the request that is blocking, not the DB as unless your
are using something like m$ access (eeek!) then i would imagine
your DB can actually do more than one thing at once
- if you are using m$ access, change it if you can, or resign if
you can't
- re-work locking strategy to force an optimistic locking failure
if more than one update goes through - even if that involves
sticking a dummy attribute in that just increments with each
transaction
what you are suggesting feels a bit like sticking some pedals on a
car because the engine keeps stalling - probably best to fix the
engine :-)
simon
What I am doing is reporting a bug in the WebObjects API adaptor,
with the circumstances as how how I encountered it. It might be
possible to deduce, for example, that the application list etc (see
config.c in the Adaptors project) is in shared memory, while
uniqueID_counter (see transaction.c) is not in shared memory, but
should be, if we cared.
Anybody reading this list who is interested in the adaptor?
---
Regards Patrick
OneStep Solutions (Research) LLP
www.onestep.co.uk
This email, including any attachments, is confidential and intended solely for
the person or organisation to whom it is addressed. If you are not the intended
recipient you must not disseminate, distribute or copy any part of this email
nor take any action in reliance on it.
If you have received this in error please notify the sender immediately by
email or phone +44 (0)1702 426400 and delete this email and any attachments
from your system.
Email transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept liability
for any errors or omissions in the contents of this message which arise as a
result of email transmission. If verification is required please request a
hard-copy version.
OneStep Solutions LLP is registered in England and Wales under registration
number OC337173 and has its registered office at 457 Southchurch Road,
Southend-on-Sea, Essex SS1 2PH.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]