Re: paper on Prevayler

Nice!

How much are you planning to dive in to the details? 

There is a lot of text in the short-long-transaction-section that I more or less read as "A long transaction usually becomes long because of business logic being a part of the transaction". Perhaps it could simply say that. I've seen many newcomers to prevalence implementing systems this horrible way, and that includes myself.

In the snapshot-speed-section you could consider mentioning hypothetical solutions to speed things up: native heap-dumps, decoupling classes at serialization and recoupling them at deserialization so they can be deserialized using multiple threads, etc.

I also think there should be a bit about text about portability and domain class refactoring. What's possible to do with java.io.Serializable out of the box (adding new fields but not renaming, etc), that sometimes it's easier to dump data of previous system version in some independent format and import to the next version refactored version of the system, while others implement their own serialization strategy with domain class versioning and built in refactoring (I did that using java.io.Externalizable but it was quite a hassle and thus never did it again), etc. 


		karl

On 04 Aug 2014, at 04:40, Ralph Johnson <[email protected]> wrote:

> Klaus and I are writing a "pattern paper" about Prevayler.   An early draft is at https://drive.google.com/file/d/0Bx60GDHHyv4TMENlRTFsOGNDSk0/edit?usp=sharing
> 
> I expect this paper to end up 10-12 pages long, which will be twice what it is now.  I'd love to get advice on what to add.
> 
> Does anybody have references for example systems?
> 
> At the moment, I am thinking that "small transactions" is not really a pattern, but a set a patterns.  The paper currently talks about measuring the length of transactions so you can find which ones are long.   I think that is a pattern.  It also talks about having a separate transaction for each employee in a payroll system instead of just having a "write checks" transaction.   That is another pattern.   I've thought of writing about continuations as a way of breaking up a big transaction into smaller ones.   That would also be a pattern.   Can you think of patterns in how you break big transactions into small ones?
> 
> I think you can leave comments in the document, or e-mail them to us.  Or post them here.
> 
> -Ralph Johnson
> 
> ------------------------------------------------------------------------------
> 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

------------------------------------------------------------------------------
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