Steven Harris's Blog

Why I started the Mnemos Project.

Just as there is no one language that is universally suitable for every programming task, so is it in the world of software APIs. I have often found that one size does not fit all.

Sometimes the task at hand may require an API that provides a high degree of flexibility, extensibility and/or transparency. Simplicity and a small footprint may be required on some other project. Yet another may require support for certain standards and interoperability with other APIs. Any one API may support all these characteristics (and more) to one degree or another but every API will have to make certain tradeoffs.

In the world of object persistence there exists a plethora of APIs. For example, there are many implementations of JDO, O/R tools such as Hibernate and TopLink and POJO style persistence systems such as JBoss TreeCache to name but a few. JavaSpaces can be viewed in a general sense as a distributed persistence mechanism. All of these operate somewhat differently and provide degrees of advantage and disadvantage depending upon the context in which they are applied.

Mnemos is yet another object persistence system. It leverages Java's native persistence format -- namely Serialization. Mnemos provides a simple and powerful API for storing and retrieving serializable objects based upon the Java type system. I started the Mnemos Project to provide a layer on top of Serialization that enhances its use as a persistence mechanism.

Serialization is a deep copy operation. Whenever an object is flattened and reconstituted, a separate and equal copy of that object is produced wholly independent of the object from which it was originally serialized. Mnemos caches persistent objects to ensure that all threads within a single JVM see the same instance.

Sub-references to persistent objects within a persistent object graph are converted to proxies in the serialized output stream. When these object graphs are deserialized the real subjects of the proxies are realized at runtime ensuring that the topology of persistent object graphs is maintained.

At the time of this writing Mnemos offers three persistent collections -- namely MnemosStorableLinkedList, MnemosStorableLinkedHashMap, and MnemosStorableLinkedSet. Each functions identically to their respective Java Collection class namesakes except that they are Mnemos storable and each persistent object in the collection is stored as a proxy whose real subject is realized at runtime when the element is first accessed. This allows large collections of persistent objects to be loaded into memory quickly and provides a lazy loading that conserves memory when access to only a few objects from the collection is required.

In an ideal world objects would require neither special preparations nor special declarations to enable their persistence. Although Mnemos falls short of this ideal, it is designed to minimize the preparation required. By running an application under the MnemosClassLoader all classes that implement the Serializable interface (except for Java System classes which can not be enhanced) are automatically prepared for persistence via byte-code enhancement. If using the specialized class loader is undesirable for some reason, then the MnemosStorable interface can be implemented by hand with only 5 lines of code.

So if you're developing a small to medium size single user application and you require a quick and simple method of persisting your objects check out Mnemos. It's light-weight and may be just the fit you're looking for.

Comments

• Have you looked at Prevayler, which uses a similar - although more invasive - concept, based on object serialization?

  Or Hibernate, which is also surprisingly easy to bootstrap once you drink their koolaid?

  Not to disparage the inventiveness - and I like the name - but it's yet another storage technology that's really too lightweight to be used in anything but VERY tiny apps. (Of course, you say that outright, so kudos to you.)

  Posted by: epesh on January 05, 2005 at 04:07 AM

• Other projects that fill similar needs include
  XCollections,
  Smyle, and
  JDBM. They are all pure Java and can be freely used in any project. The Mnemos dependency on either MySQL or the Berkeley DB make it less flexible in that respect. There doesn't seem to be anything preventing Mnemos on top of JDBM or Smyle, however.

  On a coding note, why doesn't MnemosStorable extend Serializable?
  - Curt

  Posted by: coxcu on January 05, 2005 at 07:52 AM

• Thanks for posting this, it looks cool. I'll probably try it out tonight.

  Posted by: ronaldyang on January 05, 2005 at 11:25 AM

• Hi Curt,

  Thanks for your comments and thanks for telling me about XCollections and Smyle. I had not heard of them and I will go check them out. I am familar with JDBM. When I first developed Mnemos, I had considered writing three datastore implementations. The third was going to use JDBM. Guess I just ran out of steam.

  There is really no good reason (that I can think of ) why the MnemosStorable interface should not extend Serializable. I guess I was thinking that most applications would use the MnemosClassLoader which specifically looks for Serializable classes to enhance.
  For those developers who prefer to implement the MnemosStorable interface by hand, I can see how extending from Serializable would make things easier . Thanks for pointing this out.

  - Steve

  Posted by: sfharris on January 05, 2005 at 07:51 PM

This work is licensed under a Creative Commons License.