[
https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546351
]
Xavier Hanin commented on IVY-492:
----------------------------------
I start to work on this issue, sorry Geoff for the delay, you should have
pinged us.
Anyway, to give some feedback about what we said previously on this issue, I
plan to integrate Geoff patch to make resolvers transaction aware, and will try
to implement basic atomicity in the file system resolver. I don' plan to use
commons-transactions, which seems a bit overkill for what we want to do, and
doesn't really do what we want. Indeed it seems that commons-transactions
ensure transaction properties like atomicity only when you use
commons-transactions for reading too. This would change the filesystem resolver
quite a lot, and wouldn't tackle the problem where a fs resolver is used for
publish and another one for reading ( as happens in some cases).
So I plan to make the publish atomic with fs resolver by relying on the
atomicity of the rename operation on the underlying filesystem. According to
what I've seen it seems that NTFS and POSIX based filesystems offer atomic
rename on a single drive, so implementing atomic publish should be as simple as
publishing to a temporary location and renaming at the end.
> support atomic publish operation
> --------------------------------
>
> Key: IVY-492
> URL: https://issues.apache.org/jira/browse/IVY-492
> Project: Ivy
> Issue Type: New Feature
> Components: Core
> Reporter: Geoff Reedy
> Assignee: Xavier Hanin
> Attachments: ivy-transactions.patch
>
>
> Some resolver types (e.g. one that uses subversion) could benefit from
> publishing a module as a single atomic transaction. Currently, each artifact
> (and it's checksums) are published as separate operations, if one of the
> artifact uploads fail (perhaps an artifact is missing or another user is
> trying to publish the same version at the same time) the ivy repository can
> be in an inconsistent state with a half published module. In addition, if
> uploads are logged many entries in the log are generated for a single logical
> operation.
> A possible implementation strategy is to add three new methods to the
> resolver interface:
> beginPublish(ModuleRevisionId)
> abortPublish()
> commitPublish()
> beginPublish would be called before publishing the artifacts of the module,
> abortPublish would be called if there is an error while publishing the
> module, commitPublish would be called if all artifacts were successfully
> published. Existing resolvers could simple implement these methods as no-ops
> to retain the present behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
