Re: SLING-2530 (CRUD) Persisting changes
Hi Vidar, 2012/7/6 Vidar Ramdal : > From https://cwiki.apache.org/confluence/display/SLING/Supporting+CRUD : > "Changes are not persisted immediately but stored transient. When all > changes are done, a save/commit calls needs to be done trying to > persist all changes to all resource providers." > > Let's say a changeset involves several resource providers, which in > turn are called to save the changes, and the second resoure providers > fails. > What will happen to the changes already saved by the first resource > provider? Should these be rolled back? Yes, basically I think so - now I guess the next question is what happens if rollback is not possible? I think we can either choose one of two ways: - persist each change immediately; this was my initial idea. But obviously this has performance and consistency drawbacks. Consistency could be sovled with JTA transactions. - keep changes in a transient space and have an explicit save call The second option seems more natural and as long as only one resource provider is affected by the changes, everything is fine. The problems start as soon as changes go to different resource providers. In that case a rollback mechanism is required but can fail as well. I'm not sure if we can solve all the use cases, so I think we're fine if we have this :) Carsten > > -- > Vidar S. Ramdal > Webstep AS - http://www.webstep.no > Besøksadresse: Lilleakerveien 8, 0283 Oslo > Postadresse: Postboks 272 Lilleaker, 0216 Oslo -- Carsten Ziegeler cziege...@apache.org
Re: SLING-2530 (CRUD) Persisting changes
On Fri, Jul 6, 2012 at 12:07 PM, Carsten Ziegeler wrote: > ...I think we can either choose one of two ways: > - persist each change immediately; this was my initial idea. But > obviously this has performance and consistency drawbacks. Consistency > could be sovled with JTA transactions. > - keep changes in a transient space and have an explicit save call > > The second option seems more natural and as long as only one resource > provider is affected by the changes, everything is fine IMO, having only one writable resource provider should be the standard case, the one that we design for. Multiple writable resource providers might be cool in theory, but supporting it 100% is a lot of work, we might keep that for later. -Bertrand
Re: SLING-2530 (CRUD) Persisting changes
2012/7/6 Bertrand Delacretaz : > On Fri, Jul 6, 2012 at 12:07 PM, Carsten Ziegeler > wrote: >> ...I think we can either choose one of two ways: >> - persist each change immediately; this was my initial idea. But >> obviously this has performance and consistency drawbacks. Consistency >> could be sovled with JTA transactions. >> - keep changes in a transient space and have an explicit save call >> >> The second option seems more natural and as long as only one resource >> provider is affected by the changes, everything is fine > > IMO, having only one writable resource provider should be the standard > case, the one that we design for. > > Multiple writable resource providers might be cool in theory, but > supporting it 100% is a lot of work, we might keep that for later. > I think having multiple writable resource providers is fine and might make sense. Depending on the kind of data you're storing, you're using a different provider and that's transparent to the client code. However I agree, that even in that case, the standard use case is to do changes to a single resource provider at a a time. Carsten > -Bertrand -- Carsten Ziegeler cziege...@apache.org
