• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WO blocking/threading question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WO blocking/threading question


  • Subject: Re: WO blocking/threading question
  • From: David Teran <email@hidden>
  • Date: Sat, 14 Aug 2004 12:29:13 +0200

Hi Michael,

This is something that after reading all the books and docs I still don't fully get.
If I have a site where 100 users come to the site at the same instant and all do a search (i.e. a SELECT, not an UPDATE or INSERT or DELETE) also at the same instant (hypothetically), does WO block while each request is handled? It seems that in the default deployment that WO only uses a single database connection and in the case of my JDBC driver (postgresql), the driver is synchronized so only a single call can be made through one JDBC connection at a time. If it doesn't block on SELECT, does it block when doing SQL updates/deletes?


WO uses one EOF stack by default. All EOEditingContexts' object store is one and the same. You can create additional EOF stacks like this:

// stack # 1
EOObjectStoreCoordinator osc1 = new EOObjectStoreCoordinator();
EOEditingContext ecStack1 = new EOEditingContext(osc1);

// stack # 2
EOObjectStoreCoordinator osc2 = new EOObjectStoreCoordinator();
EOEditingContext ecStack2 = new EOEditingContext(osc2);

Now if you do a fetch with ecStack1 which takes lets say one hour or so you can do another fetch in parallel with ecStack2. Each EOF stack uses at least one JDBC connection.


I can't really see how this can be the case since it would seem that WO would be the worlds slowest application server unless you always had 100 or more instances running at the same time for a high volume site.


On a related note, I have queries that are non-JDBC related (legacy data) that use pooled network connections that I control and dole out to the user on request. Does WO block while for these types of requests are being processed? I put these legacy queries in a WOLongResponsePage in an effort to allow multiple users to be calling the legacy system at the same time because according to the docs these spawn new threads. The legacy system can take 5-10 seconds to responsd in most cases.

My limited understanding is that at least the request/response cycle is threaded so that if you just have a WO app that doesn't do any database access, it will handle concurrent requests just as any other application does.


the RR loop is single threaded by default, you can turn it on by putting 'WOAllowsConcurrentRequestHandling=true' in a properties file or as commandline argument. Then the RR loop runs in multithreaded mode which means multiple request are processed in parallel. If each request uses another EOF stack then you have parallel database access, too.

Be aware that multithreaded apps tend to have more EOF deadlocks, so you really should know what you are doing. Some people are reporting that they have to problems with concurrent request handling as long as they are using the sessions default editingcontext, but fetching everything in one editingcontext is not a good idea (imho).

regards David
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: WO blocking/threading question
      • From: Michael Engelhart <email@hidden>
References: 
 >WO blocking/threading question (From: Michael Engelhart <email@hidden>)

  • Prev by Date: Re: Accessing WOAssociation in WOComponent with 5.2.3
  • Next by Date: Hardware/Software License Inventory Model?
  • Previous by thread: WO blocking/threading question
  • Next by thread: Re: WO blocking/threading question
  • Index(es):
    • Date
    • Thread