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 On 6 December 2010 13:52, r...@synapticstorm.com <r...@synapticstorm.com>wrote: > Hi Patrick, > > Couldn't you just use WOLongResponse so that it keeps the first connection > alive until it responds? > > Regards, > > Rob. > > On 6 Dec 2010, at 13:09, Patrick Middleton wrote: > > > I have an app doing something superficially like web services which is > sessionless and accessed via DirectActions. Because of other activity in > the database sometimes, database i/o can block for several minutes. When > this happens the Apache WebObjects adaptor's loadbalancing features come > into play, and redirect the request it sent to an apparently unresponsive > instance to a different instance, which may in turn block on database i/o. > The caller's browser waits several minutes and then receives an "no > instance available" page. When the other activity in the database clears > an, if the request caused a database update, that update can be applied > multiple times because of each instance attempting to process the request. > If the first update changes the database in a way that prevents the other > updates from succeeding, they might report "update failed", and if the > database i/o hold up was only a few minutes, that page can be returned to > the caller -- a page saying that the update failed, when in fact the update > succeeded but the caller won't get to see that page. > > > > What I thought about doing, and have largely done, is announce and listen > for activity via multicast datagrams. If an instance receives a request via > a direct action and I don't want it to be redirected via the load balancer, > enough information is broadcast such that other instances waiting for > requests will be able to tell that another instance should already be > processing it, and then generate a response (without blocking on database > i/o) to the effect that database congestion may be in progress, that their > request is being processed, any database updates may or may not be committed > but will be committed at most once. > > > > But what constitutes "enough information"? The WebObjects adaptor adds a > header "x-webobjects-request-id" (aka REQUEST_ID_HEADER, in config.h) to a > received request before writing it to an instance (this header is not > "leaked back" to the client) and this appears to be unique: 24 chars long > corresponding to three hexstrings of 32-bit numbers, being the time at which > some initialization code was called in the process (httpd), the process > identifier (of httpd), and a unique sequence counter defended by a lock. > The point at which this header is added means that a redirected request > will have the same x-webobjects-request-id header. > > > > And so to the subject line of this message: "x-webobjects-request-id > lacking uniqueness?" Of those 24 chars, the first 16 are effectively fixed > whenever httpd starts, and I appear to be seeing values being reused for the > last 8. I'd guess that either the shared memory or the locking isn't > working as expected. > > > > Anybody else seeing this? > > > > --- > > 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 (Webobjects-dev@lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > > http://lists.apple.com/mailman/options/webobjects-dev/rob%40synapticstorm.com > > > > This email sent to r...@synapticstorm.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk > > This email sent to si...@potwells.co.uk >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
