Hi, there are times when a "random" ID would be OK, but I (and as I can see Ran) needed a sequentially generated ID (or sequence number). In this case, you have to persist the last ID in the DB and read-increment-store when the next ID is to be generated.
But this multihreaded issue could come up in other use cases as well, so it is nice to know there's a "Neo4j synchronization" way to do this properly without causing a deadlock. --- balazs On 11/3/11 9:57 AM, Tuure Laurinolli wrote: > On Nov 2, 2011, at 13:33 , Balazs E. Pataki wrote: > >> Hi, >> >> I had a similar issue (also with ID generation), and I would be also >> interested in a solution, or how synchronizations should be done to >> avoid deadlocks like this in the transaction. > > Have you considered using IDs that can be generated without consulting the > database, or even in-VM synchronization? E.g. UUID, GUID or VMID. > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
