f4b6a3 / tsid-creator Goto Github PK

625f545#commitcomment-99677378

When using the Tsid.encode method in a JDK 8 environment, an error is occurring due to TWO fields in a BigInteger.
This needs to be fixed so that the encode method can be used in JDK 8 environments.

Make the TimeIdCreator wait the next millisecond instead of throwing a TsidCreatorException.

Twitter Snowflake also waits the next millisecond:

sequence number - 12 bits - rolls over every 4096 per machine (with protection to avoid rollover in the same ms)

  protected def tilNextMillis(lastTimestamp: Long): Long = {
    var timestamp = timeGen()
    while (timestamp <= lastTimestamp) {
      timestamp = timeGen()
    }
    timestamp
  }

See this line:
https://github.com/twitter-archive/snowflake/blob/b3f6a3c6ca8e1b6847baa6ff42bf72201e2c2231/src/main/scala/com/twitter/service/snowflake/IdWorker.scala#L97

Hi.
Can you give me some explanation of what is the difference between tsid and uuid v7?
Are they actually doing the same thing? can they be replaced by each other?

Methods to optimize:

• TsidCreator.createString()
• TsidConverter.toString()

System property: tsidcreator.node.count.
Environment variable: TSIDCREATOR_NODE_COUNT.

Inspiration: The best UUID type for a database Primary Key, by Vlad Mihalcea

Currently, TsidFactory does not accept a random function that returns null. The random function is used to reset the counter when the millisecond changes. If this function returns null, an exception is thrown.

TsidFactory can ignore the null return and just increment the counter value.

Currently, the TsidFactory.create method is synchronized:

public synchronized Tsid create() {

	final long _time = getTime() << RANDOM_BITS;
	final long _node = (long) this.node << this.counterBits;
	final long _counter = (long) this.counter & this.counterMask;

	return new Tsid(_time | _node | _counter);
}

But, the synchronized is needed for getTime only. So, it is getTime that should be synchronized instead because of the timestamp monotonicity issues:

private synchronized long getTime() {

	long time = clock.millis();

	if (time <= this.lastTime) {
		this.counter++;
		// Carry is 1 if an overflow occurs after ++.
		int carry = this.counter >>> this.counterBits;
		this.counter = this.counter & this.counterMask;
		time = this.lastTime + carry; // increment time
	} else {
		// If the system clock has advanced as expected,
		// simply reset the counter to a new random value.
		this.counter = this.getRandomCounter();
	}

	// save current time
	this.lastTime = time;

	// adjust to the custom epoch
	return time - this.customEpoch;
}

This will reduce the scope of the Thread contention, especially when using a ThreadLocalRandom generator.

Hello, first of all I'd like to congratulate the maintainer for this wonderful project.
I'm wondering if, due an unavailability to provide a node identifier, the ThreadLocalRandom approach described on README is significantly safe to generate ids on a small cluster, < 10 nodes, assuring low probability of collision.

// use a random function that returns an array of bytes with a given length
TsidFactory factory = TsidFactory.builder()
    .withRandomFunction(length -> {
        final byte[] bytes = new byte[length];
        ThreadLocalRandom.current().nextBytes(bytes);
        return bytes;
    }).build();

// use the factory
Tsid tsid = factory.create();

My best regards.

See: f4b6a3/ulid-creator#32

Change TsidValidator to check the maximum value: 7ZZZZZZZZZZZZ = 9223372036854775807 (2^63 - 1)

Could you make the Tsid class extensible?
Can you remove the final modifier from class and changing the number field from private to protected?

Use case: For some entities like Tenant and User I have specialized IDs that differentiate them from others.

To extend Tsid I had to copy the classes into my project and modify them, but I would like to use the original library for that.

Goal 1: produce formatted TSID.

String format = "K%S";
String key = Tsid.fast().format(format); // key: K0AWG1PRQQFZ8D

String format = "DOC-%S.pdf";
String filename = Tsid.fast().format(format); // filename: DOC-0AWG1PRQQFZ8D.pdf

Goal 2: parse formatted TSID.

String format = "K%S";
String key = "K0AWG1PRQQFZ8D";
Tsid tsid = Tsid.unformat(key, format); // tsid: 0AWG1PRQQFZ8D

String format = "DOC-%S.pdf";
String filename = "DOC-0AWG1PRQQFZ8D.pdf";
Tsid tsid = Tsid.unformat(filename, format); // tsid: 0AWG1PRQQFZ8D

Hi,

First of all, thanks for this library. I haven't used it yet, but it looks promising. I'm working on a project with Spring/Hibernate/MySql classical stack on a multitenant environment, where there is a database catalog per tenant. Additionally, some tenants data could be consolidated in a different catalog as they belong to the same organization. Anyway, my requirement is to generate primary keys in a way where future clashes can be avoided. This is where this library fits. My initial thought was to assign a different node id for each tenant, but the library is designed assuming that node id is immutable. So, my questions are:

• Does my approach make sense?.
• If so, do you think that this requirement could be fit in your library?.
• If not, my idea is to clone the repo and make an implementation where the create method receives an overriding node id. What do you think about this approach?.

Thanks for your time.
Best regards,

Juan Carlos

Keep monotonicity in case of small clock drift.

Implement a convenience method to generate quick TSIDs.

Tsid tsid = Tsid.fast();

AtomicInteger will be employed by this method.

Security-sensitive applications that require a cryptographically strong pseudo-random generator should continue to use TsidCreator.getTsid().

Do you have any suggestions on how to get a node id in a simple way on Kubernetes?

Add this line to MANIFEST.MF:

Automatic-Module-Name: com.github.f4b6a3.tsid

Change TsidValidator.validate() from protected to public.