We looked at all the transaction logging, but found that there was no clean way to get the DML statements. And I agree, that would really be a great way to handle the replication, as we would essentially just be playing back logs. Unfortunately it does not seem that there is a way to do that with H2 right now (although I might be missing it)
We also took a look at SymmetricDS. The overhead of the extra tables/ columns and the relatively heavyweight replication was not ideal for us. So, sadly, we are using triggers (well -- one trigger over and over again) on individual tables (they do not work on the session table). The end result will be fine, but it will be quite a bit of code to get the change objects cleanly converted to SQL. Thank you all for your suggestions. On Mar 16, 4:24 am, chenson42 <[email protected]> wrote: > If you don't mind the trigger approach, then SymmetricDS (http:// > symmetricds.org) might be a > possible solution. It has great support for H2 and has been used to > replicate/synchronize changes > out to thousands of H2 clients. > > On Mar 15, 4:15 pm, Dario Fassi <[email protected]> wrote: > > > Hi, > > > I have a similar need and wondered if it would be possible implement > > some form of transaction log retention, > > based on the CheckPoint command , trace file and ConvertTraceFile tool. > > > El 15/03/10 16:46, [email protected] escribió: > > > > Right now I am looking for the best way to capture changes on the > > > "primary" before blasting them out to the "secondaries". Ideally, I > > > would be able to catch the CRUD/DML SQL so that I can just sent that > > > along to all of the secondaries. This is particularly desirable as > > > bandwidth would be kept to a minimum. However, it does not look like > > > there is a good way to do that. So far we have looked into: > > > > * JDBC proxy to get the information out. Possibly the cleanest > > > solution, > > > * Using triggers. This gives me objects, both new and old, but that > > > is not something that would work well shipping to the secondary H2s as > > > it can be large as well as requiring "diffing" to get the actual > > > change set. > > > * Getting the change set out of JPA 2.0. This does not work in all > > > situations. > > > In my experience, JDBC proxy for this purpose is possible but far to be > > trouble and cost free. > > Using triggers and replication tables to persist replication events and > > data it's possible too, but according to model size and complexity can > > be an overwelming effort and a nightmare for maintenance. > > > If we can do some type "transaction logging retention" in a sql format > > (or java executable) form the problem becomes almost trivial. > > > regards, > > Dario -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
