On Dec 6, 2010, at 6:20 AM, 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

It would be EOF that is blocking when the OSC gets locks.  Concurrent request 
handling won't address the problem that Patrick is seeing.  It would just be  
the difference between one thread waiting on EOF and one thread  waiting on EOF 
and N threads waiting on the OSC lock.  Using multiple EOF stacks will address 
this unless the point of contention really is in the database.


Chuck


> - 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/chill%40global-village.net
> 
> This email sent to ch...@global-village.net

-- 
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/products/practical_webobjects







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

Reply via email to