Child pages
  • EOF-Using EOF-Concurrency

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Using ThreadLocals for Accessing Multiple EOObjectStoreCoordinators

Brendan Duddridge

We're trying to fix some of our editing context issues we've been having and we're thinking of creating an architecture like the following:


Does anyone foresee any undesired issues with this approach? I've never seen this approach postulated in the WO dev archives. One of my developers suggested this approach and I thought it sounded good, so I'd see what others thought first before implementing it. We'd be happy to share our findings and code if it works out well.

David LaBer

I've worked on an application architected this way, and was not happy. Just so you know where I'm coming from (smile)


As always these opinions are my own, and are open to discussion (smile)

Chuck Hill

Locking-wise, I think that will be fine. Memory usage is the most likely issue that you will run into. The extra EOF stacks will consume more memory than a single stack implementation. I'm assuming that this is OK for your purposes, that the requests will not be fetching in a lot of data. If they do fetch a lot of data, or you do end up with many worker threads, you may find that you apps runs out of memory rather quickly. You might want to consider some sort of round robin usage of a set of stacks stored at the app level. This will at least somewhat limit memory usage. You may also get more optimistic locking failures at the database like this. If you are running multiple instances (which I recall is the case) you have to handle these anyway so that becomes a non-issue.