ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David E Jones <d...@me.com>
Subject Re: Optimistic locking based on timestamps
Date Fri, 13 Aug 2010 00:26:12 GMT

What do you mean by "nests transactions"? I'm not aware of OFBiz doing anything like that,
and in the few contracts I've worked on where clients used MySQL it's not something I've run


On Aug 12, 2010, at 4:33 PM, Matt Warnock wrote:

> We also determined a few months ago that some ofbiz code apparently
> nests transactions, which MySQL does not support, at least as of 5.5,
> which we were looking at then IIRC.
> -- 
> Matt Warnock <mwarnock@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
> On Thu, 2010-08-12 at 16:19 -0600, David E Jones wrote:
>> On Aug 12, 2010, at 3:21 PM, James McGill wrote:
>>> On Thu, Aug 12, 2010 at 1:52 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>> This is why I prefer to use PostGres but that's another story and of course
>>>> the same problem could occur at the ms level, 1000 time less though...
>>>> Jacques
>>> I was hoping you would post to tell me I was wrong, and  point out the
>>> locking semantics in the delegator that the application can use.
>>> My current plan is to extend the delegator and minilang so that "findOne"
>>> and <entity-one> can have a "for update" parameter, so that at least the
>>> application can decide to do a select for update, to introduce some locking
>>> to avoid concurrency bugs.
>>> Right now, it's fairly common to for us to issue inventory items until the
>>> quantity goes below zero, because there's no way to regulate concurrency
>>> between two threads that want to issue.   There are many parts of the system
>>> where this might not be such a problem, but on InventoryItem it's a
>>> potential nightmare.
>>> What do you think about my idea of giving the delegator a "select for
>>> update"  option?
>> Adding a for-update option is a good idea, and is something I have incorporated into
the Moqui design.
>> As Jacques mentioned chances are you'll still have a better experience with Postgres
when it comes to concurrency issues, in the way they manage transactions and locking in addition
to the timestamp resolution issue.
>> I honestly don't know why so many people like MySQL compared to Postgres, but I know
that many people do.  Maybe it's the greater marketing budget of corporate-driven MySQL versus
the more community-driven Postgres. It's also a shame that when SAP DB was scavenged for useful
things to go into MySQL that it wasn't done the other way around, ie take useful things from
MySQL and put them into SAP DB. Of course, I haven't looked into the state of either code
base before this was done, but I do know which organization acquired the other and that probably
drove the direction for the software (it's bad marketing to come out and say you're tossing
most of your main software stack to go forward with another). 
>> I could certainly be wrong, and if any MySQL fans out there want to help me understand
why maybe it will even make it through my shield of bias.
>> -David

View raw message