[
https://issues.apache.org/jira/browse/TINKERPOP-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120403#comment-18120403
]
ASF GitHub Bot commented on TINKERPOP-3282:
-------------------------------------------
kenhuuu commented on PR #3639:
URL: https://github.com/apache/tinkerpop/pull/3639#issuecomment-5879219478
I think one of the existing design choices made for the original
TinkerTransactionGraph causes real problems with this implementation. The
decision to make every attempt to lock that conflicted throw a
TransactionException made sense when TinkerTransactionGraph was just for unit
testing transactions. However, since this is now supposed to be a fully capable
production-ready Graph, that logic doesn't really hold. When there are multiple
users, even moderately concurrent workloads might result in immediate
TransactionExceptions that the user will need to retry themselves.
Some choices made here exacerbate the situation.
1. The need to acquire locks on elements and then a global lock which then
calls `fsync` while holding all the locks means that these locks are held even
longer than before.
2. A compaction will block every commit
So lock contention was already going to be a problem before, but this
current design requires you hold these locks for even longer. I don't think
users will find it acceptable that they are constantly getting
TransactionExceptions. We probably need to move to a lock wait solution which
while increases the chances of deadlock or we drastically reduce the time you
need to hold the locks and add retry for transactions into the GLVs. Either
would probably result in a better user experience.
> TinkerGraph file persistence
> ----------------------------
>
> Key: TINKERPOP-3282
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3282
> Project: TinkerPop
> Issue Type: Improvement
> Components: tinkergraph
> Affects Versions: 3.7.6
> Reporter: Stephen Mallette
> Assignee: Stephen Mallette
> Priority: Major
>
> Give TinkerGraph a basic file persistence option tied to its transactional
> usage so that it can support some more complex use cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
