I don't know, I'm inclined to think these lists do a better job of sharing
information in a searchable manner than Jira does.
Regards
Scott
On 19/02/2017 00:36, "Jacques Le Roux" wrote:
Thanks Scott,
As I referred to the thread it could help people to fix related issues if
they stumble upon. E
Thanks Scott,
As I referred to the thread it could help people to fix related issues if they stumble upon. Else if you think it's confusing, please feel free to
change the summary and description, maybe by adding your comment below?
Jacques
Le 18/02/2017 à 11:37, Scott Gray a écrit :
There
There was no bug report in this thread, just some vague details. Deadlocks
are not simple to locate and fix, finding the competing transactions is
difficult even with access to the logs and database. I don't think there's
any point in filing a ticket unless Robb comes back with more details about
Hi Scott,
I was referring to the bug which was initially reported in this thread. I understand that we should rather refactor FinAccount services and I have
opened a Jira for that
https://issues.apache.org/jira/browse/OFBIZ-9221
Jacques
Le 18/02/2017 à 08:06, Scott Gray a écrit :
Which bug
Which bug are you referring to Jacques? FinAccount services certainly need
to be refactored but the use case that I mentioned was unusual so it
probably isn't worth fixing unless a more common scenario comes along. It
just happened to be a simple example I had on hand.
Regards
Scott
On 18/02/20
+1. Feel free to investigate and create when applicable.
Best regards,
Pierre
On Friday, February 17, 2017, Jacques Le Roux
wrote:
> I mean if it still exists in trunk and R16.11
>
>
> Le 17/02/2017 à 13:51, Jacques Le Roux a écrit :
>
>> Hi Scott,
>>
>> Should we not open a Jira and try to fi
I mean if it still exists in trunk and R16.11
Le 17/02/2017 à 13:51, Jacques Le Roux a écrit :
Hi Scott,
Should we not open a Jira and try to fix this bug?
Jacques
Le 16/02/2017 à 04:04, Scott Gray a écrit :
For example, a current project has some heavily used FinAccount rows and
the OFBiz
Hi Scott,
Should we not open a Jira and try to fix this bug?
Jacques
Le 16/02/2017 à 04:04, Scott Gray a écrit :
For example, a current project has some heavily used FinAccount rows and
the OFBiz implementation has a tendency to modify the child rows
(FinAccountAuth/FinAccountTrans) before mo
Thanks Scott! Much appreciated. The pattern makes sense. Have a great
weekend.
On Wed, Feb 15, 2017 at 8:05 PM Scott Gray
wrote:
For example, a current project has some heavily used FinAccount rows and
the OFBiz implementation has a tendency to modify the child rows
(FinAccountAuth/FinAccountTr
Then you have not the infamous problem of ms
https://issues.apache.org/jira/browse/OFBIZ-2208 and it's another issue indeed
Jacques
Le 16/02/2017 à 00:08, Robb Wagoner a écrit :
It is AWS Aurora variant of MySQL v5.6.10.
$ mysql -hofbiz.example.com -e 'select version(), @@aurora_version'
+---
For example, a current project has some heavily used FinAccount rows and
the OFBiz implementation has a tendency to modify the child rows
(FinAccountAuth/FinAccountTrans) before modifying the parent FinAccount
row. This very easily results in a deadlock as soon as one of the
competing transactions
5/5.6 :).
-邮件原件-
发件人: Robb Wagoner [mailto:r...@pandastrike.com]
发送时间: 2017年2月16日 7:09
收件人: user@ofbiz.apache.org
主题: Re: MySQL Deadlocks in OfBiz 12.04
It is AWS Aurora variant of MySQL v5.6.10.
$ mysql -hofbiz.example.com -e 'select version(), @@auro
It is AWS Aurora variant of MySQL v5.6.10.
$ mysql -hofbiz.example.com -e 'select version(), @@aurora_version'
++--+
| version() | @@aurora_version |
++--+
| 5.6.10-log | 1.10 |
++--+
On Wed, Feb 15, 2
Hi Robb,
Just to be sure, the MySQL version you use >= 5.6.4 ?
Jacques
Le 15/02/2017 à 20:03, Robb Wagoner a écrit :
We are running OfBiz 12.04 and are using MySQL 5.6 as the RDBMS. We are
experiencing database deadlocks and would like to be able to add
MySQL-specific statements to deal with
Thanks Scott. Since I am new to OfBiz can you provide a code example? I.e.
by what means are you issuing an arbitrary no-op update statement on a
parent row?
On Wed, Feb 15, 2017 at 1:02 PM Scott Gray
wrote:
Hi Robb,
I've encountered similar deadlocks in the past and have simply issued an
updat
Hi Robb,
I've encountered similar deadlocks in the past and have simply issued an
update statement on the main row before attempting to work with any child
rows. That has the same effect as the FOR UPDATE statement but without
needing to enhance the framework.
Regards
Scott
On 16/02/2017 08:03,
We are running OfBiz 12.04 and are using MySQL 5.6 as the RDBMS. We are
experiencing database deadlocks and would like to be able to add
MySQL-specific statements to deal with the deadlocks. For example: `SELECT
... FOR UPDATE` on PRIMARY KEYs and/or FOREIGN KEYs in the transactions.
Being new to
17 matches
Mail list logo