Kyle Moffett wrote:
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.
Wow! This does sound simple in theory. Of course I have much to learn
about jgit code base first.
Any pointers on what parts of the code are involved that I should start
looking at? I would hate to
keep a fork of gjit around. Would this work be of interest to the
project if it could be done in a way
that a few properties control whether to use database or not?
Thanks Kyle!
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
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
--
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
