Hi Adrian, I'll probably have plenty of questions, but the first that comes to mind is: how would you use a delegator outside of a transaction with this approach?
Thanks Scott On 25/08/2014, at 10:51 am, Adrian Crum <[email protected]> wrote: > One persistent problem with the current Entity Engine implementation is the > use of ThreadLocal variables in the Delegator and Transactions. Their use > makes it difficult (and sometimes impossible) to fix Entity Engine bugs. They > also make it impossible to multi-thread a Delegator instance. > > Here is what I have had percolating in my head the last few months: > > Transaction tx = TransactionFactory.newTransaction(); > Delegator delegator = tx.getDelegator("default"); > // Do stuff with delegator > Transaction nestedTx = TransactionFactory.newTransaction(); > Delegator nestedDelegator = nestedTx.getDelegator("default"); > // Do stuff with nestedDelegator > nestedTx.commit(); > tx.commit(); > > A Delegator instance always references the transaction it is running in. > > The advantage to this approach is we gain the ability to hand off Delegator > instances to other threads. Other threads can even commit/rollback a > transaction: > > Transaction tx = delegator.getTransaction(); > tx.commit(); > > After a commit, the Delegator instance is discarded. Any attempt to use it > after a commit throws an exception (the same is true with the Transaction > instance). > > Another problem is Delegator localization - which also uses ThreadLocal > variables. We can localize Delegator instances like this: > > Transaction tx = TransactionFactory.newTransaction(); > Delegator delegator = tx.getDelegator("default", locale); > > Finally, the current implementation has a caching problem: > https://issues.apache.org/jira/browse/OFBIZ-5534 > > With the new design, the Delegator instance, Transaction instance, and entity > cache are tightly coupled - so that problem is easy to solve. > > What do you think? > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com
