609 words

object creation during pmf.getPersistenceManager()

#1
2011-07-28 10:37

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

Tomasz
Tomasz's picture
Joined on 2011-07-11
User Post #21
#2
2011-07-29 13:41

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.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #488
#3
2011-08-01 07:47

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

Tomasz
Tomasz's picture
Joined on 2011-07-11
User Post #22
#4
2011-08-01 19:13

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)
    }
}
ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #494
#5
2011-08-02 06:39

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

Tomasz
Tomasz's picture
Joined on 2011-07-11
User Post #23
#6
2011-08-08 08:23

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

Tomasz
Tomasz's picture
Joined on 2011-07-11
User Post #24
#7
2011-08-08 10:38

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.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #508

Post Reply

Please read carefully the posting instructions - before posting to the ObjectDB website.

  • You may have to disable pop up blocking in order to use the toolbar (e.g. in Chrome).
  • Use ctrl + right click to open the browser context menu in the editing area (e.g. for using a browser spell checker).
  • To insert formatted lines (e.g. Java code, stack trace) - select a style in the toolbar and then insert the text in the new created block.
  • Avoid overflow of published source code examples by breaking long lines.
  • You may mark in paragraph code words (e.g. class names) with the code style (can be applied by ctrl + D).
  • Long stack traces (> 50 lines) and complex source examples (> 100 lines) should be posted as attachments.
Attachments:
Maximum file size: 32 MB
Cancel