As I see the main drawback of using serialized data is that its hard to do a data migration. If a jbdc database was used, this issue could have sorted with a simple DB migration. +1 to resume the work that Jane has started. We should try to write standard sql queries as much as possible to support any database and also we could provide DDL scripts for MySQL (production usage) and H2 (testing/demo purposes)
On Sat, Nov 28, 2015 at 11:45 PM, Imesh Gunaratne <im...@apache.org> wrote: > A good suggestion Isuru! > > I think the best option is to move the registry based data store to a > database due to many reasons. Jane started this effort sometime back but it > was halted. > > Thanks > > On Tue, Nov 24, 2015 at 3:35 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> Hi Devs, >> >> We are heavily using serialization to store context/runtime data >> throughout Stratos, and we depend on the default serialization mechanism >> provided by Java. The downside of this is if a Serialized class is changed >> (adding/removing a non-transient and non-static class variables), we cannot >> use any data serialized with the older version of the same class. The only >> option in this case is to start with a new deployment of Stratos. >> >> Currently since we are using the default serialization/deserialization >> capabilities by implementing Java Serializable interface, we have no >> control over this process. But, if we implement Externalizable [1] >> interface, we actually can have some control over the >> serialization/deserialization. With this, its the responsibility of the >> implementing class to maintain the serialization/deserialization logic. >> >> To maintain the backward compatibility of serialized data, AFAIU we can >> do the following: >> >> - Maintain a version for serialized classes (ex.: >> CloudControllerContext - version 4.1.4) >> - Write our own serialization/deserialization logic, depending on the >> version >> - If a change occurs to the class such that previously deserialized >> data can not be used (adding a non-transient member to the class, etc.), >> increment the version of the relevant class and modify the deserialization >> logic as shown in [2] >> >> Therefore, even in there is a change to the class signature, still the >> already serialized data can be de-serialized from the previous version. I >> did a quick PoC for custom serialization and deserialization using >> CloudControllerContext class, which worked fine. >> >> There are few downsides of this approach though: >> >> 1. Maintain our own serialization/deserialization logic, requires >> updating if a change occurs in the relevant classes >> 2. The Externalizable interface requires a default non argument >> Constructor to work, and that will require some design changes (since we >> have private/non-default constructors in a few singleton Context classes) >> >> wdyt? >> >> [1]. >> https://docs.oracle.com/javase/7/docs/api/java/io/Externalizable.html >> >> [2]. >> if ("4.1.4".equals(CC_CONTEXT_VERSION)) { >> // de-serialize members in 4.1.4 version >> } else if ("4.1.5".equals(CC_CONTEXT_VERSION)) { >> // de-serialize members in 4.1.5 version >> } >> >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048* <http://wso2.com/>* >> >> >> > > > -- > Imesh Gunaratne > > Senior Technical Lead, WSO2 > Committer & PMC Member, Apache Stratos > -- Sajith Kariyawasam *Committer and PMC member, Apache Stratos, * *WSO2 Inc.; http://wso2.com <http://wso2.com>* *Mobile: 0772269575*
