ODB should auto-restart if it detects it's necessary

#1

Hi!

I find very tricky the need to restart ObjectDB server after schema modifications in a distributed environment. Moreover, not doing it does sometimes trigger ugly errors, which mean application downtime.

It might be very useful to have an additional feature (that could be enabled/disabled in objectdb.config) that each time ObjectDB detects a schema change that requires restart, it should automatically restart itself. This way we save a lot of headaches from our dev. ops.

Currently we have to manually do:

  1. Deploy new version of the application
  2. Wait for it to serve first requests, so that ObjectDB gets the updated persistent java classes
  3. See that ODB triggers an error
  4. Restart ObjectDB

All these could be easily done just through this feature that I'm suggesting.

Moreover, this would considerably reduce the chances of corrupting the database. (A problem that I've suddenly encountered in the last days because of these schema changes without restart, which gave us a lot of problems and needed a lot of time for debugging and fixing).

This is the error I got after adding a new field into a class, then renaming it after a few minutes:
com.objectdb.o._PersistenceException: Failed to read the value of field field xxx.xxx.entity.p2.ExerciseSetResult.rest using reflection
at com.objectdb.o.BYR.s(BYR.java:113)
at com.objectdb.o.BYR.z(BYR.java:194)
at com.objectdb.o.NLT.readAndAdjust(NLT.java:109)
at com.objectdb.o.UMR$S.C(UMR.java:1014)
at com.objectdb.o.UMR.B(UMR.java:602)
at com.objectdb.o.UML.v(UML.java:549)
at com.objectdb.o.MMM.ag(MMM.java:1066)
at com.objectdb.o.UTY.aH(UTY.java:1301)
at com.objectdb.o.UTY.aG(UTY.java:1273)
at com.objectdb.o.ENH.b(ENH.java:102)
at com.objectdb.o.LDR.J(LDR.java:796)
at com.objectdb.o.LDR.z(LDR.java:218)
at com.objectdb.o.OBC.aP(OBC.java:1052)
at com.objectdb.o.OBC.aN(OBC.java:957)
at com.objectdb.o.OBC.UH(OBC.java:791)
at com.objectdb.o.SRB.l(SRB.java:158)
at com.objectdb.o.QRR.m(QRR.java:545)
at com.objectdb.o.QRR.f(QRR.java:211)
at com.objectdb.jpa.JpaQuery.getResultList(JpaQuery.java:686)
at xxx.xxx.extra.ReadWorkoutPlan.read(ReadWorkoutPlan.java:36)

This is how the error looks like if I enhance the classes before execution with:

Enhancer.enhance("xxx.xxx.entity.p2.*");
com.objectdb.o.InternalException: null
at com.objectdb.o.BYR.s(BYR.java:113)
at com.objectdb.o.BYR.z(BYR.java:194)
at com.objectdb.o.NLT.readAndAdjust(NLT.java:109)
at com.objectdb.o.UMR.readAndAdjust(UMR.java:653)
at xxx.xxx.entity.p2.ExerciseSetResult.__odbReadContent(ExerciseSetResult.java:1)
at com.objectdb.o.MMM.ag(MMM.java:1064)
at com.objectdb.o.UTY.aH(UTY.java:1301)
at com.objectdb.o.UTY.aG(UTY.java:1273)
at com.objectdb.o.ENH.b(ENH.java:102)
at com.objectdb.o.LDR.J(LDR.java:796)
at com.objectdb.o.LDR.z(LDR.java:218)
at com.objectdb.o.OBC.aP(OBC.java:1052)
at com.objectdb.o.OBC.aN(OBC.java:957)
at com.objectdb.o.OBC.UH(OBC.java:791)
at com.objectdb.o.SRB.l(SRB.java:158)
at com.objectdb.o.QRR.m(QRR.java:545)
at com.objectdb.o.QRR.f(QRR.java:211)
at com.objectdb.jpa.JpaQuery.getResultList(JpaQuery.java:686)
at xxx.xxx.extra.ReadWorkoutPlan.read(ReadWorkoutPlan.java:36)

This gave a big headache, and we couldn't get rid of it until we repaired and created a new db with ObjectDB Doctor.

Therefore, I would really appreciate this new feature in ObjectDB, which would definitely avoid corruption situations, which could be very problematic in production environments.

I have the odb file that triggers this error, but I don't want to put it public on the forum.

Moreover, what I found strange was that ObjectDB Explorer didn't have any problem reading all ExerciseSetResult entities. This error happened just in code or tests, but not through ObjectDB Explorer.

I look forward to hearing from you. I'm using version 2.5.4_05

#2

We are aware to this problem and providing a solution is in high priority.

ObjectDB already contains a mechanism for supporting live schema evolution without restarting the server, but unfortunately this fails in some cases, and providing a complete solution requires some major changes.

Restarting the server automatically may cause other issues, so a better solution is probably required.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
#3

Thanks for your replies to all my forum threads.

I understand what you're saying now, but how should I approach this problem then?

This scenario can still happen, and it's not at all desired.

#4

You should approach this problem by strict upgrade procedure which includes restarting the server. If you do that this scenario should not repeat.

If you can provide a test application and instructions how to reproduce the problem it could help in providing a solution in the short term. In the long term the entire ObjectDB type system is expected to be rewritten to be more dynamic, and then schema evolution will be more natural and this issue will not exist.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply

To post a reply and/or subscribe to update notifications - please login