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. 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. Thanks, Brett On Tue, Jul 20, 2010 at 6:55 PM, Scott Gray <scott.g...@hotwaxmedia.com>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 > > > >
