Anti-pattern: inadequate Persistence System

Persistence requires properly supporting things like

• Atomicity
• Consistency
• Concurrency
• Durability
• Crash recovery
• Scalability
• Performance
• Security
• Physical independence
• Logical independence
• Federated data
• Redundancy, backup and fail over
• Replication and synchronisation
• Schema evolution
• Read and write caching
• Indexing
• Query support, including query optimisation
• Configuration management
• Integrity constraints
• Asynchronous I/O
• Prefetching

These are the kind of features offered by a Database Management System (DBMS).

These are complex and difficult features to implement that require significant expertise from very experienced systems programmers.

Therefore it is preferable for these features to be provided uniformly across all types of data in the enterprise to amortize their significant development cost. A DBMS needs to be very general in terms of the supported data types and access patterns so that data that needs to be updated atomically can live in a single database.

Clearly we cannot expect desktop applications to develop their own proprietary DBMS, and we see that in practice many desktop applications tend to have very basic support for data management (typically data is simply stored in files). Hopefully there will be a trend for these applications to work on top of a proper DBMS.

There are many products on the market which promote inadequate systems for persisting data. For example, you're asking for trouble if you persist data in ActiveMQ Artemis which is marketed as Flexible and Fast Message Persistence. Persistent message systems that can only persist things in queues introduce significant problems related to atomic commit []. Even the most basic atomic updates cannot be expressed. For example, usually when a producer produces something it came from somewhere else, and the transfer of that something needs to be atomic.