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:
Note first... we have WOAllowsConcurrentRequestHandling = true
So what we'll end up with is a separate connection to the database for each worker thread. So we could potentially have many connections to the database. As worker threads are finalized, we'll close the connection to the database. We may end up using the JavaPoolingJDBCAdaptor to limit the connections to the database. But this would provide for good multi-threaded concurrent access to our application.
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.
I've worked on an application architected this way, and was not happy. Just so you know where I'm coming from
A couple of thoughts:
As always these opinions are my own, and are open to discussion
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.