Hi Brett, I'm no expert on this stuff but a few comments inline.
Regards Scott On 23/07/2010, at 1:04 PM, Brett Palmer wrote: > Scott, > > Thanks for this information. I think the instanceId solves the problem for > the Service engine and the JobSandbox table. > > Do you know if OFBiz has a similar solution for other tables that might have > problems with concurrency? We ran into some problems with the order and > inventory tables when we ran with multiple application servers. The problem > was that ofbiz doesn't appear to support a "select for update" type of > query. This makes it difficult to guarantee that when one application > server reads a record (e.g. an inventory record) and then updates it that > another application server doesn't read the same record and update it as > well. We had to work around this issue by writing custom SQL to do the > "select for update" call. I think we may have discussed this before but my understanding is that selecting a row within a transaction essentially locks that row for the duration of the transaction. I've experienced that first hand in a situation where I was trying to update a row by suspending the current transaction, starting a new one, performing the update, committing and resuming the original transaction. It didn't work because the original transaction had performed a select on that row which locked it, preventing the new transaction from performing the update. > Are there any plans to implement this type of feature in the entity engine? > Another approach I have seen implemented called "optimistic locking". This > is where the entity engine checks the timestamps on updates to make sure the > timestamp has not been modified since the record was first read. This type > of feature is needed any many ERP like applications. Is there a way in > ofbiz to do this now. Search the mailing lists for this, I'm pretty sure David described (within the last few months) how OFBiz could (or does) support this with the use of those timestamp fields. > > Thanks, > > > Brett > > > > On Tue, Jul 20, 2010 at 6:55 PM, Scott Gray <[email protected]>wrote: > >> Give each instance it's own instanceId in general.properties and everything >> should be fine. The JobManager periodically polls looking for jobs that >> aren't assigned, queued or cancelled and then assigns them to its instance >> using the instanceId and queues them. >> >> It would probably take me as long to explain fully as it would for you to >> just go to the JobManager.poll() method and have a look at it :-) >> >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 21/07/2010, at 12:27 PM, Craig Ambrose wrote: >> >>> I have a multiple instance deployment backed by a single database. I have >> a user-triggered event that creates a JobSandbox entry that is to execute a >> week in the future. Is it (reasonably) guaranteed that the job will only be >> executed by a single instance? It would be bad for our customers if the job >> is executed by more than one of the instances. >>> >>> Can anyone shed some light on what mechanism is responsible for ensuring >> that only one runtime instance will execute a certain job? >>> >>> Thanks >>> >>> -craig >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
