Connection performace after upgrade to objectdb 2

Hi,

I have performance problems with objectdb 2 when I tried to get the PersistenceManagerFactory and PersistenceManager :

In objectdb 1 :

PersistenceManagerFactory pmf =
  JDOHelper.getPersistenceManagerFactory(
    getProperties(physicalPath, objectName), JDOHelper.class.getClassLoader());

takes only 3ms

and

PersistenceManager pm = pmf.getPersistenceManager();

takes 40ms

However, with objectdb 2, the same instructions take respectively :

257ms and 238ms which is very expensive.

Could you please help me to understand what is wrong with that ?

Attached the two odb file for version 1 and 2.

ps. I run the doctor this odb file, indexes seems to be fine

Regards,

Just tried to create PersistenceManagerFactory and PersistenceManager for your database using ObjectDB 2, with the following test:

import javax.jdo.*;


public final class T976 {

    public static void main(String[] args)  {
        for (int i = 0; i < 5; i++) {
            long time = System.currentTimeMillis();
            PersistenceManagerFactory pmf =
                    JDOHelper.getPersistenceManagerFactory(
                            "$objectdb/db/LogTestRunV2.odb");
            System.out.println("Obtaining PersistenceManagerFactory: " +
                (System.currentTimeMillis() - time));
            for (int j = 0; j < 5; j++) {
                time = System.currentTimeMillis();
                PersistenceManager pm = pmf.getPersistenceManager();
                System.out.println("Obtaining PersistenceManager: " +
                    (System.currentTimeMillis() - time));
                pm.close();
            }
            pmf.close();
        }
    }
}

The output is:

Obtaining PersistenceManagerFactory: 550
Obtaining PersistenceManager: 722
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 1
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManagerFactory: 2
Obtaining PersistenceManager: 192
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManagerFactory: 1
Obtaining PersistenceManager: 171
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 1
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManagerFactory: 1
Obtaining PersistenceManager: 177
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManagerFactory: 1
Obtaining PersistenceManager: 135
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0
Obtaining PersistenceManager: 0

The first creation of PersistenceManagerFactory and PersistenceManager per PersistenceManagerFactory are slow, but this is normal since many one time initialization operation are required.

But when repeating these operations they are very fast.

Usually PersistenceManagerFactory should be built once and then used to create many PersistenceManager instances, and that is very fast.

Thank you very much for you reply.

The problem is that in my software, customers needs to load a component that depends on many odb file, the idea is to be able to dispaly data from any of them at any time later.

So I need to create PersistenceManagerFactory and PersistenceManager as many as the number odb files I need to load.

For example, in the previous version, for 100 odb database, it takes 24 secondes, which is still acceptable.

Now, for the same thing, it takes 50 secondes (which the double)

Do you have any idea how can I solve this issue ?

It does not seems to be possible to reuse the PersistenceManagerFactory for different odb ?

Regards

You cannot use the same PersistenceManagerFactory for different databases.

Conventional use of ObjectDB usually doesn't involve working with so many odb files at the same time, so ObjectDB was never optimized for this purpose.

I tried a modified version of the test above that opens 10 copies of your database:

import javax.jdo.*;

public final class T976 {

    public static void main(String[] args)  {
        for (int ix = 0; ix < 9; ix++) {
            long time = System.currentTimeMillis();
            PersistenceManagerFactory pmf =
                    JDOHelper.getPersistenceManagerFactory(
                            "$objectdb/db/LogTestRunV2_" + ix + ".odb");
            System.out.println("Obtaining PersistenceManagerFactor: " +
            (System.currentTimeMillis() - time));
            time = System.currentTimeMillis();
            PersistenceManager pm = pmf.getPersistenceManager();
            System.out.println("Obtaining PersistenceManager: " +
                (System.currentTimeMillis() - time));
            pm.close();
            pmf.close();
        }
    }
}

The results are better than what you got:

Obtaining PersistenceManagerFactor: 565
Obtaining PersistenceManager: 688
Obtaining PersistenceManagerFactor: 1
Obtaining PersistenceManager: 202
Obtaining PersistenceManagerFactor: 1
Obtaining PersistenceManager: 182
Obtaining PersistenceManagerFactor: 2
Obtaining PersistenceManager: 158
Obtaining PersistenceManagerFactor: 2
Obtaining PersistenceManager: 112
Obtaining PersistenceManagerFactor: 1
Obtaining PersistenceManager: 149
Obtaining PersistenceManagerFactor: 2
Obtaining PersistenceManager: 149
Obtaining PersistenceManagerFactor: 1
Obtaining PersistenceManager: 105
Obtaining PersistenceManagerFactor: 1
Obtaining PersistenceManager: 84

Apparently most time is spent on looking for classes and JDO metadata in the classpath (for synchronization with the database), and this could be optimized. However, any further work will require a more realistic test that reflects your real database and includes classes, JDO metadata, etc.

Thank you very much for you reply.
However, do you know why the connection cost in objectdb 2 is higher than objectdb 1 ?

Regards

Maybe new features of ObjectDB 2 (JPA XML metadata, annotations for JPA/JDO, etc.) affect initialization performance (more files to look for and analyze), but without a realistic test case, this is just a guess.

Ok, thank you very much.