You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Geoff Reedy (JIRA)" <ji...@apache.org> on 2007/05/01 21:36:15 UTC
[jira] Created: (IVY-492) support atomic publish operation
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
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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494982 ]
Xavier Hanin commented on IVY-492:
----------------------------------
It seems we'd better have agreed on our jira/mailing list guidelines :-)
I see an advantage of using directly the file resolver for this and modifying the Repository and DependencyResolver interface directly: people could benefit of this without changing their settings, by simply droping the appropriate jar in their classpath. And you could control atomicity with a simple property on the resolver (transactional="true" for instance).
OTOH, with explicit transactional resolvers, you can raise an error if the jar is not available. But we could also do that if one set explictly the property 'transactional' (which could actually the values true, false, or auto (the default value) for automatic detection.
And if we later provide transactional support for other resolvers (maybe all), it will make the settings easier IMHO.
WDYT?
> 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
>
> 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.
[jira] Assigned: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin reassigned IVY-492:
--------------------------------
Assignee: Xavier Hanin
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494976 ]
Gilles Scokart commented on IVY-492:
------------------------------------
Why not just having a separated separated TransactionalFileResolver ? We have a 0 dependency rule for out-of-the box resolver, but not for 'optional' resolver.
Of curse, if we do that, we have anyway to find an implementation the begin, abort, commit.
We put an empty implementation for the classical resolver. Alternatively, instead of adding the three methods to the resolver interface, we could make it 'optional' by adding the three methods in a subinterface of resolver or a to separated interface.
> 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
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Geoff Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495633 ]
Geoff Reedy commented on IVY-492:
---------------------------------
FYI, I have ported the changed that my 1.4 patch does to the 2.0 code. However, the patch is at home and I am at work. I will try to remember to post it to this issue when I get home tonight.
My 1.4 patch actually did create an additional interface called TransactionalResolver, but for 2.0 I added them directly to the DependencyResolver interface. Perhaps my reasons for the choices I made each time will be helpful.
When I was writing my patch for 1.4 I wanted as little intrusion into the rest of the ivy code as possible so I created an additional interface and implemented it in my resolver. Thus, the only ivy code I had to modify were the publish and install methods of the Ivy class. This made my patch smaller since I didn't have to worry about adding those methods to any other resolvers.
However, the change would have been simpler if I could have depended on the DependencyResolver interface having the transaction methods which is the path I took porting my patch to the 2.0 code. I think it also makes use of the DependencyResolver interface easier since you can see right away that there are transactional methods that should be used when calling the publish method. In my patch I have at home I added no-op implementations of the transaction methods to AbstractResolver so that none of the resolvers already provided need to be changed.
Regarding the transactional attribute, should a publish with missing artifacts ever be considered successful? It would seem that a more reasonable behavior would be to raise a MissingArtifactsException that contains the list of missing artifacts rather than returning that collection from the publish methods. Though serious thoughts about changing that (if it isn't already too late for the 2.0 timeframe) should probably go to a new JIRA issue.
> 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
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495002 ]
Xavier Hanin commented on IVY-492:
----------------------------------
Agreed for the transactional attribute, my suggestion was to add a third value, 'auto', which enable transactional behavior if the jar is in the classpath, and we could use it as default value, since I think it would be nice to make anybody benefit from transactional publication.
For the separate interface, I see your point, and I think I agree with you, with no strong preference.
> 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
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494839 ]
Maarten Coene commented on IVY-492:
-----------------------------------
For atomic publish support to filesystems, maybe we can use Jakarta commons-transactions?
> 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
>
> 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.
[jira] Updated: (IVY-492) support atomic publish operation
Posted by "Geoff Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Reedy updated IVY-492:
----------------------------
I forgot to mention that I had a patch against the 1.4 code that enabled transactions but in a more complicated way. If I have time I will simplify my patch and adapt it to the 2.0 code. It seems like it would be relatively quick to implement even from scratch, so someone might beat me to it.
> 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
>
> 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.
[jira] Resolved: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xavier Hanin resolved IVY-492.
------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-beta-1
I've applied your patch, and implemented the atomic commit in the file system resolver with some limitations (documented in the documentation).
I hope the open door will help to get more resolver supporting atomic publication.
Feel free to report any bug with this new feature.
> 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
> Fix For: 2.0.0-beta-1
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494846 ]
Xavier Hanin commented on IVY-492:
----------------------------------
Indeed, commons-transactions seems to be very well suited for this. It could work almost out of the box for file resolver at least. Very interesting. Of course to preserve our 0 dependency rule, we would gracefully degrade to no transaction management if commons-transaction is not available in classpath.
> 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
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494995 ]
Gilles Scokart commented on IVY-492:
------------------------------------
Add an additional attribute to the FileResolver seems indeed better than using a different resolver. It will be simpler for the user.
However, if we have this attribute set to true, I think we should raise an error if the dependency is not there. And if it is set to false, we should not not use the library even if it is there. So I think the transactional aspect should be driven by the value of the attribute only, and not by the presence of the dependency.
Concerning the usage of a separated interface that add the transactional aspects, I don't know what is better.
Adding the 3 methods directly in the resolver interface will force all interface to decide explicitly how they handle transaction. It can be seen as a good thing and as a bad thing.
So I would say :
-0 to add the transaction methods directly in the resolver interface
+0 to use a separated interface implemented only by the resolvers that are transaction aware (if their attribute transactional is false, they are still transaction aware)
> 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
>
> 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.
[jira] Commented: (IVY-492) support atomic publish operation
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495655 ]
Xavier Hanin commented on IVY-492:
----------------------------------
Thanks for sharing your experience, and we are looking forward to seeing your patch!
About the missing artifacts, the problem is that the publish task allow to avoid halting on missing files. So changing the method contract is not a problem, I indeed prefer using a specific exception, but we will still have to be able to deal with it in a backward compatible way from the IvyPublishTask point of view.
Then we have to answer another question: do we have to rollback the transaction when there are missing files. IMO it depends, when someone set haltonmissing to false on the publish task, I would like to commit the transaction, otherwise I would like to rollback. So maybe we could add a rollbackOnMissing attribute to the PublishOptions (defaulting to true) to be able to configure what need to be done before throwing the exception.
> 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
>
> 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.
[jira] Updated: (IVY-492) support atomic publish operation
Posted by "Geoff Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Reedy updated IVY-492:
----------------------------
Attachment: ivy-transactions.patch
This is my patch so far. It is a little rough around the edges yet and has not really gotten any testing. The basics are there though.
> 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
> 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.