I’ve got database with transaction and entity vertex types and edges of different label that are outgoing from transactions to entities. My database is in ‘automerge’ conflict strategy, and i’m doing massive optimistic batch insertion in several threads in a way that same transaction and/or it’s edges could be in multiple batches.
I’m also using Bonsai structure for edge storage, i.e. ‘ridBag.embeddedToSbtreeBonsaiThreshold=-1’.
After massive insertion is completed, i’ve ran two queries:
- select sum(out().size()) from transaction
select count(*) from E where inV() is not null and outV() is not null
and it gave me different results (1st one returned less records, than a second, second result is matching total number of edges).
“repair database” command didn’t fix anything, and reversed 2nd query (check for edges with null vertices) returned zero count.
There are no errors during insertion whatsoever, neither on my Java application side nor on OrientDB server application side.
Storage is running on ‘remote’ mode on localhost.
When I’m running massive batch insertion in serial (one thread), both queries return the same number. Could it be because some vertices are not updated in terms of Bonsai structure pointer or something? Please advice.
UPD: setting ‘ridBag.embeddedToSbtreeBonsaiThreshold=2000000000’ has led to extremely slow insertion in parallel, but both queries return same result, as well as in case with single-thread insertion. So I assume there is some problem with Bonsai structure pointers.