You'd have to go with another solution then. Is your application this
critical to write throughput or are you just thinking ahead and making sure
that it some day might need to support an amount of write throughput?
2011/11/3 Yaniv Ben Yosef yani...@gmail.com
Hi,
I've also been wondering
] Node Id generation deadlock
You'd have to go with another solution then. Is your application this
critical to write throughput or are you just thinking ahead and making sure
that it some day might need to support an amount of write throughput?
2011/11/3 Yaniv Ben Yosef yani...@gmail.com
Hi,
I've
...@lists.neo4j.org] On Behalf Of
Rick Bullotta [rick.bullo...@thingworx.com]
Sent: Saturday, November 05, 2011 11:24 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] Node Id generation deadlock
FWIW, you might be better off pipelining these writes through a single worker
thread/queue. It helps
Even without the synchronized ( _lock ) block your transactions would be
serialized as each transaction would have to grab a lock on that factory
node. So I propose you change that method implementation to:
private long generateId()
{
// This is a workaround for grabbing a write lock
This solution would have been ok if I had only one node created from that
factory in each transaction.
however, as shown in the sample code I posted in the original message, I
have multiple nodes created in one transaction, and multiple such
transactions in multiple threads.
So while the
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
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
2011/11/3 Cres cre...@gmail.com
This solution would have been ok if I had only one node created from that
factory in each transaction.
It doesn't matter... after factory.setProperty is run that transaction has
got a write lock on that factory node which is held until the transaction
committs.
Mattias: I see your point, and indeed if it weren't for the deadlock, the
transactions would have gotten serialized anyway, even without taking the
lock by removing a fake property, since we do setProperty.
However this only strengthens the question, as it further provides the need
to somehow get
Hi,
I've also been wondering about this subject.
According to the Neo4J design guide (
http://wiki.neo4j.org/content/Design_Guide) the factory node and id
generator patterns are the way to implement sequential ID generation.
However, according to this thread, it sounds like in a multi-threaded
(Sorry for re-opening this thread, I hadn't yet subscribed to the mailing
list when I opened it the previous time, so I had to re-start it..)
Hi,
I'm using Neo4J version 1.4.1. I've tried following the design guide (
http://wiki.neo4j.org/content/Design_Guide#Make_use_of_Factories ) writing a
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.
Regards,
---
balazs
On 11/2/11 8:55 AM, Cres wrote:
(Sorry for re-opening this thread, I hadn't yet
Hi Ran,
Each thread creates 2 nodes in the same transaction. The chain of events
leading to this seems to be the following:
* Thread 1 creates the first node. By the time it leaves createNode(), it
will have a write lock on the ID generator node.
* Thread 2 creates the first node. It will try to
Hi David,
Thank you very much for your response. I can see now what caused the
deadlock.
However, I'm not really sure how I can solve this problem efficiently - as
you mentioned, your proposed solution will effectively serialize my
transactions. Unfortunately, it'd be very difficult for me to
14 matches
Mail list logo
