Yuta,
You are correct. You are allowed to have multiple read transactions
accessing the same data but if you want to write to data that is
already locked by another transaction you will need to wait. If you
exceed the lock wait time you specified in your configuration file you
will received a LockNotGrantedException. Read/write transactions lock
containers (not just a single object) in the graph so it is important
to use read/writes only when you need them. If you can accomplish
most of your task in a read transaction then separate the reading and
writing portions. If you receive the LockNotGrantedException you can
always create logic to retry your transaction again. You also have
the option of using an infinite wait (-1) which will wait an unlimited
amount of time to access a resource. The only issue with an infinite
lock wait is that you may run into a deadlock exception where two
threads are trying to access data in reverse order.
If locking is a major issue considered changing your container
configuration settings:
http://wiki.infinitegraph.com/w/index.php?title=Configuration_Referen...
If you limit the size of your containers you will lock smaller pieces
of the graph. You will need to test out different values based on the
average size of your objects and how you access the graph.
Thanks,
Asher
InfiniteGraph Team
On Feb 12, 11:20 pm, Yuta Taki <yt.t...@gmail.com> wrote:
> Hello,
> I'm writing a muti-thread InfiniteGraph interface, and I sometimes see
> an exception "LockNotGrantedException."
> As I understand it, a thread wait a few seconds (I specified in the
> properties file, IG.SessionPool.ThreadBasedSessionPool.LockWaitTime)
> when the transaction has already been locked.
> Is my understanding is wrong?
> Or does this come down to a timing issue?
> best regards
