kukeltje, my idea with BAM vs BI is the following: after an execution tx that inserted records in the BAM db, those BAM records are immediately convered to the BI database. it should be possible to do this: 1) in the runtime transaction itself 2) asynchronously through messaging. the transformation to the BI db will assemble all the different logs into relevant info. then, the runtime log db will always remain small as the BAM records are max temprorary. the runtime will have the BAM db available for e.g. undo and other features that require the BI db. it should be very well documented/managed which features depend on the BI db, as it will also be configurable, which logs are being produced. we're talking next generation here and i think this covers best of both worlds. also, i'm thinking to generate a large part of the logs by leveraging hibernate's capabilities for dirty flushing. by using a hibernate interceptor, we can let hibernate calculate the diffs in one tx. that can be stored as a log record. basically each version of an object will be stored. apart from these, other logs will be generated as well. does that make sense to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978072#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...