[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] JGit thread safety
|
Thanks! I will try out the DirCache API today.
In the meantime, I'd like to add that by design of my system each user's
contents resides in a separate FS folder and each add / commit operation
operates on only one user folder. If I ensure locking around the folder
if many request by one user occur, does this change anything and make my
app thread-safe?
If not, I will take up the index approach.
Ultimately I need a repo with a working folder, to make the submitted
content available to a static HTTP server.
In this case would I need two repos? One to write resources and commit
info, and one which only pulls and checks out from the other, and serves
the HTTP server?
Thanks in advance. Sorry about this starting to sound like a general
programming consultation. I just want to understand what is the sane way
to use JGit to manage revisions of a simple FS-based CMS in a
multithreaded environment.
Regards, Dimitar
On 4/18/2013 6:54 PM, Shawn Pearce wrote:
On Thu, Apr 18, 2013 at 4:26 AM, Dimitar Georgiev
<dimitar.georgiev.bg@xxxxxxxxx> wrote:
Are local JGit operations such as commit and add thread-safe?
No. There is only one working directory. JGit assumes the caller has
managed synchronization with the working directory, since there is
only one.
I am building
a homegrown content management solution and am using JGit Command API behind
the scenes. Requests to JGit can come from multiple (HTTP) threads and I was
wondering whether having no programmatic locking around this could result in
data corruption / race conditions.
Also what is the expected results when there is a simultaneous commit /
checkout?
Don't use a working directory. The internals are thread-safe for
accessing the local repository's object database and references. If
all edits are done in-memory using the lower-level API you can do this
completely thread-safe and without the local working directory. It
requires using the DirCache to manipulate what is in the repository's
file listing, and CommitBuilder to fill out a commit. These are the
primitives used by the JGit command API.
Alternatively, make a working directory per web request. This is going
to be some really ugly code, so I wouldn't encourage it.
