Release Notes

Version 2 of MozartSpaces is the new Java implementation of XVSM that is based on the formal model. It was completely rewritten from scratch. It is incompatible with MozartSpaces version 1, but the concepts and core functionality are the same. Based on the new formal model of XVSM, it offers several new features and improved performance.

New in Version 2.3

  • none so far

Known problems

Currently, there are some known problems in MozartSpaces. The most important ones are:

  • The space/core shutdown is fragile and can fail if requests are waiting.

    Workaround: Force the application shutdown.

  • Clearing a space is not implemented.

    Workaround: Create a new core instance with an embedded space, shutdown and discard the old instance.

A complete list of the open issues is here.

New in Version 2.2

  • Breaking API changes
    • RequestCallbackHandler: signature of methods changed because generics are now used
  • Major changes
    • Added container persistence with Berkeley DB (master's thesis of Jan Zarnikov)
    • Added coordination-based authorization model to CAPI-3 (experimental!)
    • Added authentication with OpenAM to complement the integrated authorization
    • Added extensions to Query coordinator (by Martin Planer).
    • Aspects: Treat null return values as error instead of OK.
    • Rewrote the tutorial
  • Minor changes
    • Various bugfixes (see Trac report) and small changes
    • Aspects and (custom) coordinators: added methods for initialization and cleanup
    • Linda coordinator: fixed collection matching

New in Version 2.1

  • Breaking API changes
    • Aspects: Added method for test operation. This method needs to be implemented by all aspects that directly implement one of the aspect interfaces.
  • Major changes
    • Added test operation: internally it works like the read operation, but it does not return the entries, only their number.
    • Improved delete operation: it now returns the number of deleted entries.
    • Improved support for custom coordinators: The conversion between the API class and the implementation in CAPI-3 can be configured in the configuration file (further documentation coming soon).
    • Implemented meta model: Meta data can be queried from the meta model tree with a MetaModelRequest (further documentation coming soon).
    • Added REST interface (by Christian Proinger, experimental!)
  • Minor changes
    • Check the coordinator arguments in the API, not only the implementation classes.
    • Added an option to restart a core with specified configuration (experimental!).
    • Refactored CAPI-3 (use CoordinationData, coordinators, changed coordinator interface)
    • Removed the Guice dependency.
    • Updated several libraries.

Late changes in 2.0-SNAPSHOT

  • Improved the performance of implicit transactions and with many containers (scalability).
  • Changed the default value for the number of threads for socket connections from 10 to 1000.
  • Tried to fix bug #67 (count parameter in QuerySelector ignored), but introduced a new bug that is fixed in version 2.1-SNAPSHOT.

Changes in 2.0-SNAPSHOT versions

Besides bugfixes (see here) and internal improvements, there where some small API and behavior changes compared to early snapshot versions. They should result in easy resolvable compile error, except for the following changes:

  • We changed the default selector count from COUNT_MAX to 1.
  • Now the new AnyCoordinator is used as default coordinator instead of the RandomCoordinator.
  • We changed the argument order of the static methods in the coordinators to create CoordinationData and Selector objects. Please check, whether you are using any of the following methods (new versions shown below), where the signature is the same, but the semantic different:
    • KeyCoordinator: newCoordinationData(String key, String name) and newSelector(String key, int count, String name)
    • LabelCoordinator: newCoordinationData(String label, String name) and newSelector(String label, int count, String name)