On Thu, Feb 28, 2008 at 3:33 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> Note that even if the publish is atomic, the resolution itself is not. If > someone publish a bunch of module while you are resolving using some > x.latest, I'm not sure you will get a consistant result anyway. What the atomic publish ensures is that you won't ever get a resolution process seeing a module revision while it isn't fully available yet. Moreover, since Ivy caches each dynamic revision resolution during a single resolve process, you are ensured that during a single resolve, latest.integration will be resolved with only one value. What can be inconsistent is if you use several dynamic revisions, for instance latest.integration and 1.+ with a repository where the latest is 1.1, if the resolve process resolves latest.integration as being 1.1, then 1.2 is published, then Ivy resolves 1.+ as 1.2, you have some kind of inconsistency. I think this is the only kind of inconsistency you can get when you use only atomic publish concurrently with resolve processes. Xavier > > Gilles > > On 28/02/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > On Wed, Feb 27, 2008 at 8:52 PM, Shawn Castrianni < > > [EMAIL PROTECTED]> wrote: > > > > > I was curious if the filesystem resolver tries to handle any > concurrency > > > issues. For example, what happens if a module is being published at > the > > > same time someone is resolving/retrieving? Will partial modules be > > > downloaded or does it know that it isn't finished publishing so it > will > > use > > > the previous version? > > > > > > The latest version of Ivy supports an atomic publish with filesystem > > resolver: > > > > > http://ant.apache.org/ivy/history/latest-milestone/resolver/filesystem.html > > > > This relies on the atomic move of directories. > > > > BTW, the order in which Ivy publish files makes it very unlikely to hit > a > > concurrency problem even with other resolvers. Still filesystem atomic > > publish should be preferred for robustness in highly concurrent > > environment. > > > > Xavier > > > > > > > > > > > > > --- > > > Shawn Castrianni > > > CM Chief Architect > > > Landmark > > > Halliburton Drilling, Evaluation and Digital Solutions Building 2 > > > 2101 City West Blvd. > > > Houston, TX 77042 > > > Work: 713-839-3086 > > > Cell: 832-654-0888 > > > Fax: 713-839-2758 > > > > > > ---------------------------------------------------------------------- > > > This e-mail, including any attached files, may contain confidential > and > > > privileged information for the sole use of the intended recipient. > Any > > > review, use, distribution, or disclosure by others is strictly > > prohibited. > > > If you are not the intended recipient (or authorized to receive > > information > > > for the intended recipient), please contact the sender by reply e-mail > > and > > > delete all copies of this message. > > > > > > > > > > > > -- > > Xavier Hanin - Independent Java Consultant > > http://xhab.blogspot.com/ > > http://ant.apache.org/ivy/ > > http://www.xoocode.org/ > > > > > > -- > Gilles Scokart > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
