RegisterSign In
By Alfredo Sanchez (alfy) on Mar 16, 2011 11:43 AM.
Unique identifiers over transactions
Given the architecture of McKoiDDB, transactions have a snapshot view to data, that means they can't share a unique view over one of the resources consumed. In this example I'm thinking about the SQL model, where it is needed for one incremental value of an identity field: the fact a value (stored into a system table, for example) is incremented during transaction 1, would clash with another incremental of the same value made during transaction 2, that at commit would result in an exception (or at least to some inconsistency of data).

Can you think of a solution where, for a given model, there's a unique identifier, that is valid across all open transactions at the same time? I've seen (but maybe I'm mistaking it) that you implemented a solution for the problem in the ODB project (where every object instance has a single reference across transactions): would it be possible to span it across other models?
By Tobias Downer (toby) on Mar 16, 2011 7:01 PM.
The best way to make unique identifiers is to use some sort of time component plus a random value which will ensure with a high degree of probability a universal uniqueness. This is what the object system does for generating unique references for objects. It's very simple, it takes System.currentTimeMillis() and a random 64-bit value and pastes them together to form a 128-bit ID (the method is 'createUniqueIdentifier()' in com.mckoi.odb.ODBTransaction). An nice property of this is that newer entries will be sorted after earlier entries in an index.

You should definitely avoid incrementing sequences for ID generation. It's a bad practice in general in database schema design and limits scalability.
By Alfredo Sanchez (alfy) on Mar 17, 2011 4:48 AM.
I understand. And I believe the solution works properly. But I'm thinking about the situation of the auto-incremental unique keys in SQL (and sequences across transactions): displaying a 0x08D0B8D5 for a column ID it's not very fancy ... I think ...
What would be the implications in using a "static" resource, across all transactions, that keeps track of a unique ID for each table?
By Tobias Downer (toby) on Mar 17, 2011 3:07 PM.
You could always display '10' for the 10th item in the list instead of 0x08D0B8D5 when you present the result to the user. Of course '10' would fail as a foreign reference though because there's a chance that commit might change the order of records in the primary table. But you can still hide those identity values from the user.

The implications of a sequence system are that the data model commit either needs to fail on a sequence clash - which means you will need the client to replay some transactions with new ids. Or that the model needs to self correct when clashed ids are discovered (eg. if '10' clashes then change the primary key to '11' and also all foreign references to it). These issues are not limitations unless you are expecting the frequency of records added to a table with an incrementing identity to be high. However, at some point you will bottleneck writes the more ids that are generated that concurrently clash.

In my opinion, the disadvantages of incrementing identities far outweigh any other appeal and I would encourage people not to bottleneck their data with them.
Please sign in or register to post in this topic.
The text on this page is licensed under the Creative Commons Attribution 3.0 License. Java is a registered trademark of Oracle and/or its affiliates.
Mckoi is Copyright © 2000 - 2017 Diehl and Associates, Inc. All rights reserved.