【问题标题】:Serialization cons for persistence用于持久性的序列化缺点
【发布时间】:2012-08-29 17:20:24
【问题描述】:

http://docs.oracle.com/html/E24396_01/ejb3_overview_why.html获取以下给定文本

“序列化是 Java 的内置机制,用于将对象图转换为一系列字节,然后可以通过网络发送或存储在文件中。序列化非常易于使用,但也非常有限。它必须一次存储和检索整个对象图,因此不适合处理大量数据。如果在更新信息时发生错误,它无法撤消对对象所做的更改,因此不适合需要严格的数据完整性。多个线程或程序不能在不相互冲突的情况下同时读取和写入相同的序列化数据。它不提供查询功能。所有这些因素使得序列化对于除了最微不足道的持久性需求之外的所有需求都是无用的。"

我不清楚粗体字。有人可以举一个例子来支持这一点吗?

【问题讨论】:

    标签: java multithreading serialization


    【解决方案1】:

    这是一个愚蠢的观点,但这篇文章试图指出序列化实际上并没有内置“事务”的概念。当你写一个序列化的对象图时,你把整个东西写到一个流中,要么完全成功,要么失败,留下一个部分写入的流。同样的想法也适用于并发,两个不同的线程不能同时写入同一个流。

    也就是说,您可以通过将图形写入新位置并在完成后将新字节交换到旧位置来“模拟”事务存储。但是,这也取决于数据的最终存放位置(存储位置的功能)。序列化本身甚至不是一种持久性策略,因为它仍然需要在某个地方存储序列化的字节。 “并发”点遵循相同的论点,因为您可以写入 2 个不同的位置,然后使用底层存储的原子性保证来处理并发问题。

    还有其他更好的理由反对将序列化用于长期存储,即随着应用程序的类随着时间的推移而发生变化,在保持向后兼容性方面存在困难。

    【讨论】:

    • 在您写的大部分内容上,我都支持您。文中的多线程冲突是否意味着它没有像JDBC那样的读写锁机制,因此多个程序/线程不能对同一个底层持久存储进行写/读?
    • @user1633905 - 正如我试图在回答中解释的那样,序列化本身不是一种(完整的)持久性机制,因为您仍然需要一些持久性存储位置来存储结果字节。持久存储提供的锁定机制与序列化本身完全正交。
    • 是的,我现在明白了,它只是将 java 对象转换为流,没有真正支持事务/隔离行为的 api。这将是要确保的持久存储作业。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-02-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-04-15
    • 1970-01-01
    相关资源
    最近更新 更多