On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi <farrukh@xxxxxxxxxxxxxxxxxxxxx> wrote: > The problem I am trying to solve is this. In my service I need to store > metadata in a relational db and content in git such that both either commit > or not in a single transaction. If one commits and the other does not that > is a serious integrity issue. Seems to me, two phase commit would be the > right solution for that in the long run. This what JDBC + JMS topologies do. That's really easy! First tweak jgit so that *instead* of using .git/refs, it uses your database to store references and exports them on a routine basis to .git/refs for debugging purposes. Then, for each database update: (1) Start transaction (2) Commit the change to GIT (adds ref update to the transaction) (3) Make other metadata updates (4) Commit transaction Then set up periodic garbage collection and you're done! If the transaction is aborted, there will simply be a bunch of random loose objects in the git repository, which will be cleaned up the next time you garbage collect. The ref update will be atomic and conditional with the rest of the transaction, and in git the *only* part that really matters for atomicity is the ref. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
