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 <mwarn...@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.r...@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
