Forum Stats

  • 3,768,728 Users
  • 2,252,841 Discussions
  • 7,874,698 Comments

Discussions

Question regarding steps to be taken to avoid serialization issues when using JE DPL ?

Neelkamal-Oracle
Neelkamal-Oracle Member Posts: 15
edited Aug 30, 2016 11:34AM in Berkeley DB Java Edition

Hello,

I am currently using JE DPL to store an XML. I am trying to compare storing xml as a string vs java object

As expected, storing as object seems cheaper but I am concerned about possible serialization issues.

I just want to know if I need to take any additional steps to avoid serialization issues or DPL's automatic binding is sufficient ?

(Already evaluated BDB XML but BDB Java suits our use case)

Thanks,

Neel

Answers

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Aug 27, 2016 7:19PM

    Hi,

    If the XML schema often changes, then I advise storing it as a string.

    If the XML schema is very stable, then using an object may be OK, but you will be limited to evolving the schema as documented here:

    com.sleepycat.persist.evolve (Oracle - Berkeley DB Java Edition API)

    But taking a step back and looking at this decision overall, if your goal is to process and store XML, in general I don't recommend storing the XML as DPL objects. The design goal of the DPL object serialization is to store data that is represented in the application as Java objects, not as XML, JSON, etc.

    --mark

  • Neelkamal-Oracle
    Neelkamal-Oracle Member Posts: 15
    edited Aug 29, 2016 3:42PM

    Hey Mark,

    Thanks for your reply. Here is my detailed use case

    I have a web service which outputs XML string. A SAX Parser then converts XML string to a java object for further processing.

    I want to cache the XML string locally for future cases to improve performance. At this point I can either cache XML String/java object

    in berkeley db. Also, XML schema is very stable

    Based on your reply since the parser output is a java object, DPL object serialization should be sufficient. Is that correct ?

    Thanks,

    neel

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Aug 29, 2016 3:48PM

    I don't understand why you want to use a DPL-serialized object for this (rather than an XML string). This just adds restrictions, and doesn't have any advantage that I can see. But perhaps I still don't understand the use case. I don't know what you mean by "since the parser output is a java object, DPL object serialization should be sufficient".

  • Neelkamal-Oracle
    Neelkamal-Oracle Member Posts: 15
    edited Aug 29, 2016 5:18PM

    Hey Mark,

    Two reasons I was going for Parsed java object over XML String

    1) Storing Parsed java object is cheaper than XML String in terms of file system space ( about 5 times cheaper in this case)

    2) All further processing in my code is done at the object level. So, If something changes in the java object I have to convert it back to xml string

    and write to db if storing as xml string. However, if its an object I can write it directly to db.

    I am sorry if i was not clear when i said "since the parser output is a java object, DPL object serialization should be sufficient"

    what i meant to confirm was that in this case since I am using SAX parser to convert XML to java object and that java object is what is being stored in DPL

    I should be fine with DPL's object serialization ?

    Currently, I don't see any serialization issues in my prototype  but just wanted to check with you guys and make sure of any potential serialization issues

    Thanks,

    neel

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Aug 29, 2016 5:32PM

    Whether there are any compatibility issues depends on the data types used in your java class generated by your SAX parser. If all data types are supported by the DPL, then it should work. In other words, it is up to you to determine if there are compatibility issues.

    --mark

  • Neelkamal-Oracle
    Neelkamal-Oracle Member Posts: 15
    edited Aug 30, 2016 11:00AM

    Thanks Mark. I have one other question

    Is there a provision for some property/configuration flag that can be used to make berkeley db agnostic of changes to value class in berkeleyEntity ?

    Basically, I want to know if there is a way to avoid evolve,mutations in the first place ? I am looking for functionality similar to that of HaspMap with Object as value

    Ex : Map<Integer, Object> map=new HashMap<Integer, Object>()

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Aug 30, 2016 11:34AM

    Yes, to avoid any schema evolution concerns, you can store a HashMap in your DPL object. However, this negates the size advantage of using the DPL, since the field names must be stored in the map. So you might as well store the XML text instead.

    The size advantage of DPL serialization is dependent on having a schema for fields, which is represented as the Java class fields. And whenever there is a schema, there is a need for schema evolution.

    --mark

This discussion has been closed.