Hi,
We are preparing to upgrade our database servers and application dependencies from 2.6.9_04 to 2.7.6. The desired path was to upgrade the database servers to 2.7.6 first, followed by the code. I have run into issues during testing such as failures to deserialize because of incompatible stream serialVersionUIDs and mismatched .odb$ write files. Is this a supported upgrade path?
Thanks, Clinton
> the desired path was to upgrade the database servers to 2.7.6 first, followed by the code.
> Is this a supported upgrade path?
> I have run into issues during testing such as failures to deserialize because of incompatible stream serialVersionUIDs
You should upgrade the objectdb jar file on both the client and the server together (when the server is down and the database is closed) and no old objectdb jar should remain in the classpaths.
> and mismatched .odb$ write files.
When a database is closed correctly you should not have an .odb$ (recovery) file. Therefore, you should upgrade the database after it is closed properly (i.e. by closing all EntityManagerFactory instances).
Thanks for the quick response. I determined that the errors I was getting are because the 2.7.6 objectdb.jar I was using for the Database Server did not have javax.persistence and javax.tranaction. I have switched the jar that includes these dependencies and the problems disappeared. From my latest round of testing it looks like code that has a 2.6.9 ObjectDb.jar will talk to a 2.7.6 Database Server. We are not running in embedded mode. We would very much prefer not to have to upgrade the Database servers and code dependencies simultaneously. What are the consequences if we performed the upgrades incrementally (DB servers to 2.7.6 followed by code once stabilized)?
Thanks, Clinton
> From my latest round of testing it looks like code that has a 2.6.9 ObjectDb.jar will talk to a 2.7.6 Database Server.
It is possible that it will work smoothly, but we never test different versions in the client and the server, so there may be issues.
> What are the consequences if we performed the upgrades incrementally (DB servers to 2.7.6 followed by code once stabilized)?
A possible issue could be that in a case of an exception, instead of getting an ordinary exception with the correct details of the errors you will get the serialization exception, as the server is trying to send a serialized exception to the client and the client may fail to read it. This might be the case in your first report.
