ObjectDB Parsing taking huge processing time

Hi Team,

We are trying to get the Persistence Manager Factory using the code mentioned below, but it is taking a significant amount of processing time even though we don't have a large amount of data. Please let us know what could be causing this issue.

JDOHelper.getPersistenceManagerFactory(
  getProperties( aPhysicalPath, aObjectName ),
  JDOHelper.class.getClassLoader()
);

Thanks,

Vinoth

First, please try to isolate the getPersistenceManagerFactory from the methods that prepare its parameters (getProperties, getClassLoader), by preparing the parameter values in separate lines before, just to make sure that the issue is with the getPersistenceManagerFactory method (which is very likely).

The getPersistenceManagerFactory method does a lot of work so it is expected to be relatively slow. Usually this is not an issue, as it should only be called once per database. The getPersistenceManager method, which can be called many times per database to create database connections is much faster.

That said, some factors may make getPersistenceManagerFactory particularly slower, such as having a configuration file with many unused activation keys or having schema with hundreds of complex types.

To analyze your specific case please provide a test case that demonstrates the issue, or at least profiling data that shows where time is spent by this method.

Hi Team,

We have taken thread dumps during the execution, and we see that it is taking more time in the lines mentioned below. We have also attached the thread dump snapshots, which were taken at regular intervals.

The ODB files are only 256KB each; please find them attached.

 at java.net.NetworkInterface.getAll(Native Method)
        at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
        at com.objectdb.o.CFG.am(CFG.java:773)
        at com.objectdb.o.CFG.ak(CFG.java:673)
        at com.objectdb.o.CFG.aj(CFG.java:624)


java.lang.Thread.State: RUNNABLE
        at java.net.NetworkInterface.getMacAddr0(Native Method)
        at java.net.NetworkInterface.getHardwareAddress(NetworkInterface.java:472)
        at com.objectdb.o.CFG.am(CFG.java:777)
        at com.objectdb.o.CFG.ak(CFG.java:673)
        at com.objectdb.o.CFG.aj(CFG.java:624)
        at com.objectdb.o.CFG.ae(CFG.java:527)

Thanks,

Vinoth

The threads are related to checking activation keys.

Check how many activation keys you have in the ObjectDB configuration file (objectdb.conf).

You need only one activation key in development and none in the final product (when you use an OEM licence).

Thanks for your quick response, it solves the issue of slowness.

Hi Team,

One additional question regarding the activation code: We have multiple build PCs, and their activation codes have been added to the ObjectDB.conf file.

However, you mentioned that activation codes are not required in the final product because we have an OEM license. Could you please clarify how this works? Does this mean we should remove all activation codes from ObjectDB.conf in the final installer distributed to customers?

Thanks,

Vinoth

> Could you please clarify how this works? 
Simple. Classes enhanced on a developer machine with an active OEM license are signed and activated, so they don't require any activation on the end-user side. Please check whether the classes were enhanced using an OEM license, as explained here.

> Does this mean we should remove all activation codes from ObjectDB.conf in the final installer distributed to customers?
Yes

Hi Team,

Thanks for your reply. I’ve confirmed that our classes are enhanced using the OEM license, following the verification approach mentioned earlier. I have a couple of additional questions:

1. Activation code validation: Does ObjectDB validate all the activation codes listed in the configuration file, or does it stop once it finds a valid activation code?

2. OEM licensing and evaluation limits: We have encountered the error “Too many persistent objects (>1000000) – exceeds evaluation limit (error 1012)” when building the code on a PC without an activated ObjectDB license.

   If all our developer and build machines have valid activation codes, and we compile the code so that the relevant classes are enhanced and signed under the OEM license, can we safely omit the activation codes from the final JAR distributed to customers? Or could users still encounter the same evaluation-limit error when processing large logs?

Your clarification will help us finalize the changes and ensure the final product works correctly without requiring activation codes.

Thanks,

Vinoth

> Does ObjectDB validate all the activation codes listed in the configuration file, or does it stop once it finds a valid activation code?
It stops as soon as the first activation succeeds. However, if you have too many codes, it is recommended to clean out old or obsolete activations. You only need to keep enough active codes to match the number of PCs you use for building.

> can we safely omit the activation codes from the final JAR distributed to customers? 
You should definitely omit them. They will not work on different user machines anyway, and they are private, sensitive data that should not be shared. Users will encounter enhancement errors if you build with missing or partial enhancement (anyway), so it is recommended to test your application without any activation codes before distribution.