Degrading performance overtime

hi,

We have an application that uses embedded odb database. We have configured odb to start at 50meg chunks and grow at 50 megs a time.

as the files become larger between 1 and 2 gigs we start to see considerable degrade in performance caused internal objectdb locking:

"pdncrttorfo42-WSAgent-1-Existing/4" - Thread t@141
   java.lang.Thread.State: BLOCKED
at com.objectdb.o.PGC.w(PGC.java:232)
- waiting to lock <64c56ec3> (a com.objectdb.o.PGC) owned by "ODB-FileWriter" t@116
at com.objectdb.o.SNP.D(SNP.java:376)
at com.objectdb.o.OBI.v(OBI.java:443)
at com.objectdb.o.OBI.<init>(OBI.java:199)
at com.objectdb.o.PBI.<init>(PBI.java:56)
at com.objectdb.o.MST.aY(MST.java:801)
at com.objectdb.o.BQI.Ut(BQI.java:128)
at com.objectdb.o.PRG.ag(PRG.java:679)
at com.objectdb.o.PRG.af(PRG.java:553)
at com.objectdb.o.QRM.U5(QRM.java:262)
at com.objectdb.o.MST.U5(MST.java:959)
at com.objectdb.o.WRA.U5(WRA.java:291)
at com.objectdb.o.WSM.U5(WSM.java:113)
at com.objectdb.o.QRR.g(QRR.java:240)
at com.objectdb.o.QRR.b(QRR.java:151)
at com.objectdb.jpa.JpaQuery.getResultList(JpaQuery.java:686)

"ODB-FileWriter" - Thread t@116
   java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.setLength(Native Method)
at com.objectdb.o.LFL.R(LFL.java:996)
at com.objectdb.o.SFL.ah(SFL.java:998)
- locked <75608da2> (a com.objectdb.o.LFL)
at com.objectdb.o.MST.ah(MST.java:1746)
at com.objectdb.o.SFL.ag(SFL.java:958)
at com.objectdb.o.SFL.run(SFL.java:918)
- locked <64c56ec3> (a com.objectdb.o.PGC)
- locked <222c9301> (a com.objectdb.o.LKM)
at java.lang.Thread.run(Thread.java:662)

   Locked ownable synchronizers:
- None

our conf:

<!-- ObjectDB Configuration -->

<objectdb>

<general>
  <temp path="$temp/ObjectDB" threshold="64mb" />
  <network inactivity-timeout="0" />
  <url-history size="50" user="true" password="true" />
  <log path="$objectdb/log/" max="8mb" stdout="false" stderr="false" />
  <log-archive path="$objectdb/log/archive/" retain="21" />
  <logger name="*" level="info" />
</general>

<database>
  <size initial="51200kb" resize="51200kb" page="2kb" />
  <recovery enabled="true" sync="false" path="." max="128mb" />
  <recording enabled="false" sync="false" path="." mode="write" />
  <locking version-check="true" />
  <processing cache="8mb" max-threads="10" />
  <query-cache results="8mb" programs="500" />
  <extensions drop="temp,tmp,odb" />
</database>

<entities>
  <enhancement agent="false" reflection="warning" />
  <cache ref="weak" level2="0" />
  <persist serialization="false" />
  <cascade-persist always="auto" on-persist="false" on-commit="true" />
  <dirty-tracking arrays="false" />
</entities>

<schema>
</schema>

<server>
  <connection port="6136" max="100" />
  <data path="$objectdb/db-files" />
</server>

<users>
</users>

<ssl enabled="false">
  <server-keystore path="$objectdb/ssl/server-kstore" password="pwd" />
  <client-truststore path="$objectdb/ssl/client-tstore" password="pwd" />
</ssl>

</objectdb>

Please can you help us to mitigate this?

The stack trace indicates a delay during database file resize:

at java.io.RandomAccessFile.setLength(Native Method)

This is a system operation, which is apparently too slow, and blocks other operations.

You may try accelerating this operation by using the following:

    System.setProperty("objectdb.temp.no-resize-clear", "true");

Alternatively, if you know the maximum database target size, you may start with that size as an initial database size, avoiding resize operations.

If these solutions do not solve the problem, it may be possible to alter ObjectDB to avoid that lock.

could i have a better understanding of what that property does please?

By default, when a database file is extended, new file space is cleared with zeros.

With this settings, the new file space may contain garbage (such as data from old deleted files).

This should not affect ObjectDB activity and may be changed to default in future.

However, it is unclear if this alone could solve the problem.

Build 2.4.4_15 includes a change that may help in avoiding lock during database file extending.

if we perform an upgrade is it backwards compatible with old version of files e.g thoes with different versions.

Yes, it is a minor change, which should be fully forward / backward compatible.