object creation during pmf.getPersistenceManager()

Hi

  We have observed that during pmf.getPersistenceManager(), objectdb is creating object instances for all classes declared in package.jdo.   Could You explain why? we are not even sure that in that transaction we will create instances for all classes. The number of objects created during this invocation is really huge, that causes OutOfMemory during commit (memory for jvm 1,4GB). The object network is small, it was read from file via deserialization, file has size 2MB. The data model is legacy and in default constructors it create also a lot of objects, we can not change it  and we wonder what to do, we see following solution

1) switch of instance creation during getPersistenceManager() and create instances only for objects for which makePersistent is called, is it possible?

2) maybe there is posiblity to create instances not via default constructs but via clonning? it could help

moreover you have error in exception handling, bad cast is done:

java.lang.ClassCastException: java.lang.OutOfMemoryError cannot be cast to java.lang.RuntimeException
at com.objectdb.o.JDE.f(JDE.java:50)
at com.objectdb.o.OBC.onObjectDBError(OBC.java:1456)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:277)

br

Tomasz

ObjectDB creates one instance of every user defined persistable type (entity class / embeddable class / persistence capable class) using the no arg constructor - when a database is opened and a PersistenceManagerFactory / EntityManagerFactory is created. These instances serve as factory (using methods that are added during enhancement) for creation of all the managed entity objects (avoiding a more complex enhancement machanism that could have built an additional factory class for every managed class).

Since the creation of a PersistenceManagerFactory / EntityManagerFactory is a heavy one time operation (followed by many PersistenceManager / EntityManager instantiation operations, which are lighter) - in an ordinary application this should not be a problem. After all, the no arg constructors of user defined persistable type are also used during management of entity objects anyway, so they have to be light.\

You will have to refactor your classes to make the no arg constrictor lighter.

Regarding the casting of OutOfMemoryError - thank you for your report, it will be fixed on the next build.

Hi

I know that default constructors should be light, even in JDO spec it is mentioned as I remeber but i've realized that it is too idealistic approch in the real life. This system is realy legacy, developed by two handred people by sevral years so i and my friend engaged in that rescue activity for that project we are not able to refactor whole system but even if we do that, it will be first argument against changing persistence mechanism from serialization to the any object db. I think it could be better to generate constructors with argument with type from vendor or jdo domain so it allows to migrate old code.

ok, thank you for your support

br

Tomasz

Following your suggestion starting build 2.2.8_10 an alternative constructor is invoked if exists.

In JDO:

@PersistenceCapable
class EntityWithJdoConstructor {
    EntityWithJdoConstructor() {
        // doesn't invoked by ObjectDB
    }
    EntityWithJdoConstructor(PersistenceManager pm) {
        // Invoked by ObjectDB (but pm is always null)
    }
}

In JPA:

@Entity
class EntityWithJpaConstructor {
    EntityWithJpaConstructor() {
        // doesn't invoked by ObjectDB
    }
    EntityWithJpaConstructor(EntityManager em) {
        // Invoked by ObjectDB (but em is always null)
    }
}

Hi

Your support is impresive :)  We will add this constructors but it takes some time, I hope that now we will persist object network, thank You

Tomasz

Hi

 It works! We have used asm library to generate constructors with PM argument base on package.jdo file, this approach has advantage to writing constructors by hand, we skiped fields initializers which are generated by compiler into each constructor so now getting pm is very fast even having 300 PC classes. In the future it could be an option for an enhancer to generate such constructors.

thanks

br

Tomasz

Thank you for the update.

Maybe the enhancer should always add these constructors and a new configuration attribute would determine whether these constructors should be used or not.