ObjectDB Database Search

, then finally all of them get the new version? So...basically... concurrent access with version x

there couldn't be any concurrent actions on the same object? Thanks in advanced, Yotam Yotam Yotam Boaz

of concurrent threads that the database engine can serve simultaneously. When this maximum is reached, new

) ObjectDB uses automatic optimistic locking to prevent concurrent changes to entities by multiple users

;Identity and versioning mapping Annotations used to define primary keys and concurrency control

Jakarta Persistence (JPA) supports both optimistic locking and pessimistic locking . Locking is essential to avoid update collisions when concurrent users simultaneously update the same data. In ObjectDB each entity is locked separately, there is no table locking. Optimistic locking is applied

. This commonly occurs during EntityManager.refresh or EntityManager.getReference calls. Concurrency

) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util. concurrent ... ) Locked ownable synchronizers: - locked (a java.util. concurrent .ThreadPoolExecutor$Worker) "RMI TCP ... .TCPTransport$ConnectionHandler.run(TCPTransport.java:682) at java.util. concurrent .ThreadPoolExecutor

.NodeTaskWrapper.run(NodeTaskWrapper.java:150) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:511) at java.util. concurrent .FutureTask.run(FutureTask.java:266) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:511) at java.util. concurrent .FutureTask.run(FutureTask

.classmodel.reflect.Parser$3.call(Parser.java:296) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:334) at java.util. concurrent .FutureTask.run(FutureTask.java:166) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util. concurrent .ThreadPoolExecutor

) at java.util. concurrent .FutureTask$Sync.innerRun(Unknown Source) at java.util. concurrent .FutureTask.run(Unknown Source) at java.util. concurrent .ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util. concurrent .ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown

update failure among concurrent updating transactions. The persistence implementation must support

$$anonfun$get$1.apply(ApplicationProvider.scala:105) at scala. concurrent .impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24) at scala. concurrent .impl.Future$PromiseCompletingRunnable.run(Future.scala:24) at scala. concurrent .forkjoin.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask

is actually blocking/locking so I might adapt to achieve better concurrency . 1) Where are locks ... on read, is desired, should I use optimistic=true to get more concurrency ?   CBE CBE All relevant ... of multiThreaded=true . However, if you want to serve requests against the same database concurrently (not in

manager process list? Do you have several such processes running concurrently ?  When should I use ... . concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util. concurrent ... ? Do you have several such processes running concurrently ? I saw it when I ran "ps" command. Now I see it only when running

service thread 1-3) at java.util. concurrent .ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 13:49:37,714 ERROR [stderr] (MSC service thread 1-3) at java.util. concurrent .ThreadPoolExecutor ... . concurrent .ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26] at java.util

(MessageHub.java:404) at org.gradle.internal. concurrent .ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal. concurrent .ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149

(HostConfig.java:1637) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:471) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:334) at java.util. concurrent .FutureTask.run(FutureTask.java:166) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java

(MessageHub.java:414)     at org.gradle.internal. concurrent .ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)     at org.gradle.internal. concurrent ... . concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)     at java.base

.EventsImpl$1.run(EventsImpl.java:120) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:441) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:303) at java.util. concurrent .FutureTask.run(FutureTask.java:138) at java.util. concurrent .ThreadPoolExecutor$Worker.runTask

.kernel.event.EventsImpl$1.run(EventsImpl.java:120) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:441) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:303) at java.util. concurrent .FutureTask.run(FutureTask.java:138) at java.util. concurrent .ThreadPoolExecutor

(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_77] at java.util. concurrent ... .Final] at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8

-server mode. Unlike embedded mode, client server mode supports accessing a database concurrently from multiple processes (embedded mode supports concurrently only within a JVM, i.e. multithreading ... server mode supports accessing a database concurrently from multiple processes (embedded mode

.scala:222) at scala.actors.ReactorTask.run(ReactorTask.scala:36) at scala. concurrent .forkjoin.ForkJoinPool$AdaptedRunnable.exec(ForkJoinPool.java:611) at scala. concurrent .forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:422) at scala. concurrent .forkjoin.ForkJoinWorkerThread.mainLoop

communication. It could be because of concurrent use of the same connection and sockets (i.e. same EntityManager ) by two concurrent threads. ObjectDB synchronizes use of EntityManager by different threads ... concurrent use of the same EntityManager in different threads. support Support How can #2 happen

. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util. concurrent ... databases, so it can easily exceeds your VPS RAM. If you must keep 100 databases open concurrently then you will have to reduce cache sizes, etc. support Support

concurrently ? Does it have queue and cache ? 2-) is it dangerous to use that system on many online users ?   kadirbasol Kadir BASOL Having 200,000 concurrent threads is probably a bad idea. Usually ... dedicated load balancing tools. ObjectDB doesn't limit the maximum number of allowed concurrent

) [dp.transfer-1.0-SNAPSHOT.jar:1.0-SNAPSHOT] at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util. concurrent .ThreadPoolExecutor$Worker.run ... .0_45] Caused by: com.google.common.util. concurrent .UncheckedExecutionException: javax.persistence

suggests a possible concurrency issue . This could occur if the same EntityManager is accessed from multiple threads concurrently , or if the same entity instance is modified from different threads ... that EntityManager is not thread-safe , and JPA-managed entity instances cannot be accessed concurrently from

; import java.util.List; import java.util. concurrent .LinkedBlockingQueue; import java.util. concurrent .ThreadPoolExecutor; import java.util. concurrent .TimeUnit; import javax.persistence.CascadeType

like this : com.objectdb.jpa.Provider   From other beans I need concurrent access to the database ... (updatedRecord); or recordDao.storeRecord(newRecord); Other concurrent operations that I execute

(SFSEventManager.java:64) java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util. concurrent .ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang

$ConnectionHandler.run(TCPTransport.java:682) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util. concurrent .ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624 ... . concurrent .ThreadPoolExecutor$Worker) "JMX server connection timeout 74" - Thread t@74 java.lang.Thread

.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util. concurrent .ThreadPoolExecutor$Worker ... $SocketProcessor.run(JIoEndpoint.java:312) at java.util. concurrent .ThreadPoolExecutor.runWorker

to reading from the database file using the new "objectdb.temp. concurrent -file-read" option. In both cases ... from executing concurrently . But for this to work on the ObjectDB side the query must be an exact ... above that hgzwicker Hans-Georg Zwicker Build 2.7.5_03 includes an attempt to improve concurrency by replacing two main

$1.run(EventsImpl.java:120) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:471) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:334) at java.util. concurrent .FutureTask.run(FutureTask.java:166) at java.util. concurrent .ThreadPoolExecutor.runWorker

$startLineChecker$0(EventLogEntryService.java:327) at java.base/java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util. concurrent .FutureTask.runAndReset(FutureTask.java:305) at java.base/java.util. concurrent .ScheduledThreadPoolExecutor$ScheduledFutureTask.run

.InternalException: java.lang.InterruptedException: null java.lang.InterruptedException at java.util. concurrent ... ) at java.util. concurrent .Semaphore.acquire(Semaphore.java:317) at com.objectdb.o.WSM.Vb(WSM.java:171 ... (PlacesProvider.java:139) at com.golocal.MiningTask.run(MiningTask.java:65) at java.util. concurrent

while the EntityManager is manipulated concurrently in another thread (e.g. transaction is committed or ... concurrently by more than one thread? support Support We are using EntityManagers in following way ... ThreadLocal and close EM   So I think there is now concurrent access on one EntityManager. In

.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:441) at java.util. concurrent .FutureTask$Sync.innerRun(FutureTask.java:303) at java.util. concurrent .FutureTask.run(FutureTask.java:138) at java.util. concurrent

(except your new report now) is when using different versions of the same class concurrently ... . support Support I believe that the "different versions of the same class concurrently ... of the class concurrently .   heintz Anders Heintz OK. Thanks for the update. Please report if this issue

(HousekeepingProcess.java:84) at java.util. concurrent .Executors$RunnableAdapter.call(Executors.java:511) at java.util. concurrent .FutureTask.run(FutureTask.java:266) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util. concurrent .ThreadPoolExecutor$Worker.run

. concurrent .SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util. concurrent .FastThreadLocalRunnable ... .nio.NioEventLoop.run(NioEventLoop.java:493) at io.netty.util. concurrent .SingleThreadEventExecutor$4

rather than read-write lock in previous builds, when "objectdb.temp. concurrent -file-read" is enabled. Are you using "objectdb.temp. concurrent -file-read"? Do you see a change in the frequency of this exception ... the concurrent file read (System.setProperty("objectdb.temp. concurrent -file-read", "true");) 

Hi! when I run my application where 10 threads are concurrently accessing ObjectDB (only reading ... .QuantServerImpl$6.run(QuantServerImpl.java:2184) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util. concurrent .ThreadPoolExecutor$Worker.run(ThreadPoolExecutor

file is accessed concurrently by two different processes directly (i.e. not using one server process ... ? It may eliminate the small chance that the database file is somehow accessed concurrently by two instances ... two separate processes)? ObjectDB locks the database file to avoid  concurrent access by different

) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util. concurrent .ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java

.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) at java.util. concurrent .ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util. concurrent .ThreadPoolExecutor$Worker.run

workaround if it works. It may also indicate that the problem is related to concurrent use of the cache ... Sedlakova During the weekend we ran intensive tests of concurrent persist/find/remove/update operations

distinct databases concurrently ? If not and you only have one database, try to build ... is that maybe your application has 132 concurrent connections to the database (e.g. in 132