Creating serial number outside current transaction

Users are importing materials to my Neo4j db and a compact permanent id must be created for each node. I have a SerialNo node where the next number is available.

The problem is the long transaction. If I update the SerialNo node in the transaction, others users tasks hangs waiting end of my transaction.

Is it possible to execute SerialNo update independent of current transaction? One ways should be using Auto Commit transaction, but the manual warns it is not recommended in production environments for some reason. What is the problem?

Hi
Please increase transaction timeout period so that it returns all necessary information.But you will have to tune it according to your SRS.
Thanking you
Yours faithfully/sincerely
G Sameer Sudhir

How bad would if be, if the SerialNo is not continuous (skipping a number in between)? If that's not a deal breaker, you could use two transactions. Something along those lines:

def get_serial_number(tx):
    return tx.run(
        "Cypher to increase and RETURN next_serial_numner"
    ).single()["next_serial_numner"]


def do_something_with_serial_number(tx, serial_number):
    return tx.run("RETURN $serial_number AS sn",  # or whatever
                  serial_number=serial_number).single()


def do_the_thing():
    with driver.session() as session:
        serial_number = session.write_transaction(get_serial_number)
        res = session.write_transaction(do_something_with_serial_number,
                                        serial_number)

The only downside of this is, should you loose connection to the DB between succeeding with the first and the seconds transaction, the next call do do_the_thing would use the next serial number with the previous one being lost/unused.

1 Like

You might also want to give this one a read and consider UUIDs How to auto increment to get unique value for a new node's field

Thanks! I have is no problem, if serial numbers are not continuous. But my goal has been to write quite long transactions (several minutes) containing update to series of multiple nodes. I have to think about it, if it is really necessary.

Maybe I can first calculate the amount of all nodes which will be contained in the transaction, then aquire serial numbers to all the nodes and finally do the thing, but this means quite a lot refactoring.

Yes, we have now uuid keys but we should like to have a shorter key which can be easily displayed to our users.

You could base64-encode your UUID. That way it’s shorter and more or less human readable. I did that for my IDs in a project with similar requirements.

Example:
UUID (hexadecimal): 85293c93-4430-4677-9245-4711a844ba80
UUID (base 64): hSk8k0QwRneSRUcRqES6gA