Fetching contributors…
Cannot retrieve contributors at this time
212 lines (152 sloc) 8.59 KB
Changes from Prevayler 2.5 to Prevayler 2.6
Type-safety and convenience
Prevayler, PrevaylerFactory, transactions and queries are now generic types
which can be parameterized so that prevalent and return objects and values
arrive in original type form. Compiler provides you warning where you don't
do this in your code.
Existing code written with Prevayler 2.5 and earlier will still compile and
Updated demo code shows the type-safe usage.
Transactions can now be executed directly
Transactions can now allow references passed in to be used naturally, allowing
their contents to change as with Java methods. Previous versions allowed only
a deep copy to be executed.
It is activated via:
However, unrecoverable changes to the prevalent system and unrecoverable uses
of reference equality inside transactions will not fail fast as they would upon
recovery, and as they will when this is set to "true", which is still the default.
Transaction filtering is no more
Transaction filtering is no longer a feature in Prevayler. Calls to
PrevaylerFactory#configureTransactionFiltering(boolean) will no longer compile.
Changes from Prevayler 2.4 to Prevayler 2.5
Maven build and dependency cleanup
Preparation for deployment of Prevayler artifacts on Maven central.
Ie there are no behavioral changes of the code.
Removed module Skaringa and Demo2 as they use dependencies not available in
Maven central (Latest version of Skaringa XML serializer and Javamatch).
Updated all POMs to point back at parent POM rather than parent directory.
Updated all POMs to use static artifact version rather than using ${property}.
Updated all POMs to use dependencyManagement set versions of dependencies
rather than defining them over and over in module POMs.
Added <package> types to all POMs.
Added build plugins with static versions of artifact for root POM in order to
make sure it behaves the same on all environments, to define java target output,
global surefire (test) settings, javadocs and source jar output, etc.
Changes from Prevayler 2.3 to Prevayler 2.4
Maven build and dependency cleanup
Prevayler's core functionality does not have, and never has had, any external
dependencies on other libraries. The inclusion of several optional libraries
used by extensions and demos has led to some confusion about this. We have now
moved to a Maven-based build configuration which clearly distinguishes the
dependencies needed by the various extensions and demos.
Prevayler.takeSnapshot() now returns the snapshot file
In order to better support backup procedures, the Prevayler.takeSnapshot()
method now returns the file to which the snapshot was written (as a File
object). This file should be left where it is, so that Prevayler can read it
during startup, but you can copy it to another location for backup purposes if
It can be hard to tell which files generated by Prevayler need to be retained
for correct startup. It would be nice to clean up old journal files, but the
logic to decide which journals are safe to delete is subtle. Therefore we've
added the PrevaylerDirectory.necessaryFiles() method to implement the correct
logic. This method returns a Set<File> of the snapshot and journal files that
are still needed for correct system recovery. Any other files in the directory
are safe to remove.
Read snapshot 0 if it exists
Normally, Prevayler starts at system version 0 with the initial prevalent
system object passed into PrevaylerFactory.configurePrevalentSystem(), and
therefore in the past has simply ignored any version 0 snapshot. Now, Prevayler
will read the 0000000000000000000.snapshot file if it exists (and no later
snapshot files exist, of course).
Making journal disk sync optional
By default, Prevayler always ensures that every transaction is forced to be
written to the physical disk before it is executed (by FileDescriptor.sync()).
You can now turn off this behavior, increasing speed at the expense of safety,
by calling PrevaylerFactory.configureJournalDiskSync(false). This increases
transaction throughput dramatically, but allows transactions to be lost if the
system does not shut down cleanly.
No longer block calling threads when there are file errors
When there is an IOException while writing to a journal file, Prevayler needs
some way to halt processing of further transactions. In earlier releases,
calling threads would simply block, which had the result of hanging the
application. Now, an IllegalStateException is thrown to indicate that
processing has been halted.
GZIPSerializer and DESSerializer
Serializers are now provided that can wrap any other Serializer with
GZIP compression and DES or 3DES encryption.
Workaround for a Java 6 ClassLoader bug
If you specify a ClassLoader to use during journal or snapshot serialization,
you may have run into a problem due to an incompatible change in behavior of
the ClassLoader.loadClass() method in Java 6. We've replaced calls to this
method with Class.forName() as described in the Sun bug report:
Changes from Prevayler 2.0 to Prevayler 2.3
The Prevayler interface now supports an additional variation on execute(), for
transactions that return a result but don't throw Exception. A new interface
has been introduced, SureTransactionWithQuery, and a new execute() method has
been added to Prevayler taking an instance of this interface.
Journal file extension
The default filename extension for transaction journals has been changed from
'.transactionLog' to '.journal'. We always recommend taking a snapshot before
upgrading either Prevayler or your own Prevayler-based code, so there shouldn't
be any need to migrate old journal files. (The format of journal files has also
changed, so migrating old journals would require more than just renaming the
files anyway.)
Journal file format
Transaction journals now have an internal structure of their own, rather than
relying on ObjectOutputStream, in order to support configurable journal
serializers. We always recommend taking a snapshot before upgrading either
Prevayler or your own Prevayler-based code, so there shouldn't be any need to
migrate old journal files.
Optimized rollback
When using the StrictTransactionCensor, the deep-copy of the prevalent system
to perform a rollback is now implemented in a pipelined manner so as to use
significantly less memory.
Configurable serializers
A new Serializer interface has been introduced to support configuring
serialization strategies for journals and snapshots. (The existing
SnapshotManager abstract class, which had allowed limited customization of
snapshot serialization, has been eliminated.)
For snapshots, multiple Serializers may be configured, each with a different
filename extension (though the extension must always end with "snapshot" or
"Snapshot"). Only one will be used for writing snapshots, but others may be
configured to support migration from earlier versions of your own code. For
example, you might configure .v7snapshot with a Serializer including some
schema migration code, while .v8snapshot is optimized for the current version
of your business object model. The default is just .snapshot, using the
For transaction journals, only a single Serializer may be configured, since we
recommend always taking a snapshot before upgrading Prevayler or your own
Prevayler-based code, so you will never need to migrate an old journal file.
The filename extension may still be configured if desired, however (which must
end with "journal" or "Journal"). The default is .journal, using the
Other enhancements
Prevayler 2.3 includes some other behind-the-scenes improvements, including
further increased transaction throughput and fewer threads created internally.
Work on replication and an improved monitoring interface are still in progress.