Moving this discussion to the dev mailing list since the Jira issue is
closed.
Jacques,
The description of the current design can be found here:
http://ofbiz.apache.org/docs/entity.html
where it says:
"For unique primary key generation we use an original pattern we like to
call the "Ethernet Key Generation" pattern because it uses a collision
detection mechanism to insure that multiple servers can use a single
database to get banks of unique keys in a database independent way."
So, the document is making an analogy - it is saying the design is LIKE
Ethernet collision detection. The term "CSMA/CD" is an Ethernet term,
not a software design term.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/2/2014 10:10 AM, Jacques Le Roux (JIRA) wrote:
[
https://issues.apache.org/jira/browse/OFBIZ-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118052#comment-14118052
]
Jacques Le Roux commented on OFBIZ-2353:
----------------------------------------
Thanks for your explanation Adrian, so the known pattern in code litterature is
the CSMA/CD.
About performance, we should remember that the size of the bank is an important
parameter here.
If performance is a crucial concern, people might look at using solution like
CREATE SEQUENCE... Of course not in OFBiz OOTB...
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, OFBIZ-2353-AC.patch, OFBIZ-2353-AC.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)
