Fetched below given text from http://docs.oracle.com/html/E24396_01/ejb3_overview_why.html
“Serialization is Java’s built-in mechanism for transforming an object graph into a series of bytes, which can then be sent over the network or stored in a file. Serialization is very easy to use, but it is also very limited. It must store and retrieve the entire object graph at once, making it unsuitable for dealing with large amounts of data. It cannot undo changes that are made to objects if an error occurs while updating information, making it unsuitable for applications that require strict data integrity. Multiple threads or programs cannot read and write the same serialized data concurrently without conflicting with each other. It provides no query capabilities. All these factors make serialization useless for all but the most trivial persistence needs.”
I am unclear about the text in bold. Can someone quote an example to support this?
It’s kind a silly point, but the passage is trying to point out that serialization doesn’t really have a notion of “transactions” built into it. when you write a serialized object graph, you write the whole thing to a stream which either completely succeeds, or fails, leaving you with a partially written stream. sort of the same idea applies for concurrency as well, two different threads cannot write to the same stream at the same time.
that said, you could “simulate” transactional storage by writing the graph to a new location and then swapping the new bytes into the old location once complete. however, that also depends on the final resting place for the data (the functionality of the storage location). serialization isn’t really even a persistence strategy in and of itself, as it still requires somewhere to store the serialized bytes. the same argument follows for the “concurrency” point, in that you can write to 2 different locations and then use the atomicity guarantees of the underlying storage to deal with the concurrency issues.
there are other, better, arguments against using serialization for long term storage, namely the difficulties around maintaining backwards compatibility as your application’s classes mutate over time.