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]

Reply via email to