[
https://issues.apache.org/jira/browse/OFBIZ-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117465#comment-14117465
]
Jacques Le Roux edited comment on OFBIZ-2353 at 9/1/14 2:58 PM:
----------------------------------------------------------------
[~jacopoc]I also agree the code looks much better and, after reading a bit more
about it, I agree SELECT FOR UPDATE was not an optimal solution (in this case
with few chances of collisions optimist locking is faster than pessimist
locking). While reviewing I also liked how you commented enough but not much,
thanks!
I have a question:
{code}
if (stmt.executeUpdate(updateForLockStatement) <= 0) {
// This should never happen
throw new GenericEntityException("No rows changed when trying insert
new sequence row with this SQL: " + sql);
}
{code}
Why this should never happen? What if another machine/thread has just locked
the tuple before the current machine/thread? Can this never happens? If yes,
why? Else, why not retrying a couple of times (parametrized) then?
[~adri...@hlmksw.com] You suggested "UPDATE... WHERE...", could you show us the
code you have in mind (even roughly)?
Did I write too much?
was (Author: jacques.le.roux):
[~jacopoc]I also agree the code looks much better and, after reading a bit more
about it, I agree SELECT FOR UPDATE was not an optimal solution (in this case
with few chances of collisions optimist locking is faster than pessimist
locking). While reviewing I also liked how you commented enough but not much,
thanks!
I have a question:
# {code}
if (stmt.executeUpdate(updateForLockStatement) <= 0) {
// This should never happen
throw new GenericEntityException("No rows changed when trying insert
new sequence row with this SQL: " + sql);
}
{code}
Why this should never happen? What if another machine/thread has just locked
the tuple before the current machine/thread? Can this never happens? If yes,
why? Else, why not retrying a couple of times (parametrized) then?
[~adri...@hlmksw.com] You suggested "UPDATE... WHERE...", could you show us the
code you have in mind (even roughly)?
Did I write too much?
> SequenceUtil may generate duplicate IDs in Load Balancing mode
> ---------------------------------------------------------------
>
> Key: OFBIZ-2353
> URL: https://issues.apache.org/jira/browse/OFBIZ-2353
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 4.0, Release Branch 09.04, Trunk
> Reporter: Philippe Mouawad
> Assignee: Jacopo Cappellato
> Priority: Critical
> Fix For: Release Branch 10.04, Upcoming Branch
>
> Attachments: OFBIZ-2353 SELECT FOR UPDATE solution.patch, OFBIZ-2353
> SELECT FOR UPDATE solution.patch
>
>
> If Ofbiz is deploy on 2 servers in Load Balancing Mode
> SequenceUtil will generate duplicate IDs because synchronization is done at
> JVM level instead of doing it in DB.
> A good replacement implementation would be:
> org.hibernate.id.enhanced.TableGenerator
> But it would involve a dependency on Hibernate
> Philippe
> www.ubik-ingenierie.com
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
