Re: paper on Prevayler
Justin Sampson <[email protected]> Wed, 6 Aug 2014 21:51:54 +0000
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <0FD072A166C6DC4C851F6115F37DDD2763ED1172@sm-ex-02-vm.guidewire.com> |
Ralph Johnson wrote:
> A Prevayler Transaction is a Design Pattern Command. Different
> people use words like Command and Transaction in different
> ways, and it is impossible to make everybody use them the same.
> Instead, when we start to talk to a new group of people, we
> need to figure out which context they are operating in, and how
> to map our vocabularies to each other.
I never got around to writing it up, but I like to think of the
Transaction Pattern as distinct from the Command Pattern, though
of course they're similar. A Command tends to have an interface
like Java's Runnable, just a parameterless run() method, whereas
a Transaction's execute() method takes at least one parameter,
giving it access to the data that it should operate on.
A Command is the kind of thing you can stick in a GUI menu widget
to perform some arbitrary action when the user clicks on it. A
Transaction is a special kind of object that you can pass into a
subsystem to get temporary, isolated access to data encapsulated
within that subsystem.
Described that way, I've actually had good experience using the
Transaction Pattern even when using a relational database. The
usual pattern for accessing a database tends to be an explicit
sequence of actions, like:
Connection c = connectionPool.getConnection();
... do stuff with c ...
c.commit();
Using the Transaction Pattern, you'd instead submit a transaction
to a transaction manager, like this:
transactionManager.execute(new Transaction() {
public void execute(Connection c) {
... do stuff with c ...
}
});
You can see that this looks like exactly the same pattern used by
Prevayler, but passing a connection instead of a reference to the
prevalent system. Encapsulating transactions like this prevents
common errors, such as forgetting to commit the transaction or
return the connection to the pool, and allows some interesting
features like retrying transactions that fail due to lock
contention.
> The system I am working on has "prevayler transactions" and
> "business transactions". The business people mostly do not have
> to see Prevayler transactions, but programmers have to always
> stop and figure out which kind of transactions the other person
> is talking about. Usually business transactions, but not
> always.
Yep! I've been working on insurance financial software lately,
and it's pretty easy to get confused between "database
transaction" and "financial transaction." It doesn't help that we
have a dozen different _kinds_ of financial transactions in the
system.
Cheers,
Justin
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org