SLING-2530 (CRUD) Persisting changes

[Vidar Ramdal <vr...@apache.org>]

>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?

-- 
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: SLING-2530 (CRUD) Persisting changes

[Carsten Ziegeler <cz...@apache.org>]

2012/7/6 Bertrand Delacretaz <bd...@apache.org>:
> On Fri, Jul 6, 2012 at 12:07 PM, Carsten Ziegeler <cz...@apache.org> 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
cziegeler@apache.org

Re: SLING-2530 (CRUD) Persisting changes

[Bertrand Delacretaz <bd...@apache.org>]

On Fri, Jul 6, 2012 at 12:07 PM, Carsten Ziegeler <cz...@apache.org> 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

[Carsten Ziegeler <cz...@apache.org>]

Hi Vidar,

2012/7/6 Vidar Ramdal <vr...@apache.org>:
> 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 <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo



-- 
Carsten Ziegeler
cziegeler@apache.org