Actually by default OrientDB uses READ COMMITED isolation level and it's 
only available option for remote mode.
REPEATABLE READS can be used with memory or plocal modes, with a price of 
higher memory consumption.

You stated that there won't be any writes on that Graph instance, therefore 
TXs are not neccessary if you don't use REPEATABLE READS (the reads are 
always running out of TX scope) and therefore you can use non-transactional 
instance without any performance overhead caused by TX creation.

About sharing DB among threads as you said, that's a question for 
developer. However if it's possible now, my concern would be if it will 
also be possible in the future ... I think that developers are counting on 
the fact that one instance is used in one thread.

Dne úterý 15. září 2015 17:39:15 UTC+2 Alan47 napsal(a):
>
> Hi,
>
> thanks for the reply, and sorry for the late answer, these are busy times 
> for me...
>
> @Topic: To the best of my current knowledge about databases, if you don't 
> use transactions on both read and write operations, then write operations 
> cannot perform the required locking and synchronization. I assume that 
> OrientDB is no different in that matter. I also assume that "repeatable 
> reads" is the standard isolation level in OrientDB, as in all other ACID 
> databases that I am aware of.
>
> But the question is a much simpler one, actually. The OrientDB graph 
> documentation states (at several locations) that each thread must use its 
> own OrientGraph instance, obtained by calling OrientGraphFactory#tx() nor 
> #noTx(), respectively. I only want to know if it is safe to share an 
> OrientGraph among multiple threads for read-only purposes, i.e. will it 
> violate some assumptions in the caching implementation for example? This is 
> not documented anywhere, and I'm afraid only an Orient DB developer (or 
> someone with really deep insight in the code) can answer this.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to