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:
- Deploy new version of the application
- Wait for it to serve first requests, so that ObjectDB gets the updated persistent java classes
- See that ODB triggers an error
- 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