You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <ol...@zeigermann.de> on 2004/09/06 16:53:00 UTC
Re: Full caching allows corruption
I can not see how this may lead to corrupt data, could you explain,
please? What I can see is that it allows for lost updates, which is bad
enough, but a known issue.
A solution might be to employ another mechanism to guarantee more
transactionality, but the existing has some very nice featues:
(1) It works - most important ;)
(2) It never blocks and never deadlocks
(3) A commit never fails for logical reasons
If you have something that has similar features and allows for better
transactionlity, please submit it. Maybe it could be an idea to
optionally have other caches with other transactional strategies?!
Oliver
snmvaughan92mailbox-slide@yahoo.com wrote:
> I'm working with 2.1b1, and have tracked down a
> structure corruption problem to the implementation of
> the cache used by ExtendedStore. Since modifications
> to store data are performed by retrieving a cloned
> copy, modifying the copy, and then storing the
> modified copy, it is very important that other threads
> not be allowed to retrieve information from the cache
> during this process. If two threads are updating the
> same uri at the same time (i.e. modifying their own
> copies), then only the last committed copy will be
> persisted.
>
> I can eliminate this problem by disabling the global
> cache (using "isolation-shadow"). Of cource the
> performance hit for this configuration is fairly high.
> Is there some plan to update the global cache?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Thinking about transient locks already present in Slide: Don't they
assure such a scenario you describe can never happen?
Oliver
snmvaughan92mailbox-slide@yahoo.com wrote:
> The problem results from the fact that the node store
> includes a list of children.
>
> Start with a collection containing a single member
> resource {a}. Have two threads make changes to the
> collection, where one thread removes this child
> resource.
>
> Thread 1 reads {a}, adds "b" and then writes {a, b}.
>
> Thread 2 reads {a}, deletes "a", and then writes {}.
>
> Thread 1 Cache Thread 2
> -------- -------- --------
> {a} <- {a}
> {a} -> {a}
> {a, b} {}
> {} <- {}
> {a, b} -> {a, b}
>
> Since thread 1 finish last, the cache now contains an
> object which references a child "a" which does not
> exist. Since both threads intended to update the
> object, if the cache blocked during either
> transaction, then the resulting list of children would
> simply be {b}.
>
> --- Oliver Zeigermann <ol...@zeigermann.de> wrote:
>
>
>>I can not see how this may lead to corrupt data,
>>could you explain,
>>please? What I can see is that it allows for lost
>>updates, which is bad
>>enough, but a known issue.
>>
>>A solution might be to employ another mechanism to
>>guarantee more
>>transactionality, but the existing has some very
>>nice featues:
>>
>>(1) It works - most important ;)
>>(2) It never blocks and never deadlocks
>>(3) A commit never fails for logical reasons
>>
>>If you have something that has similar features and
>>allows for better
>>transactionlity, please submit it. Maybe it could be
>>an idea to
>>optionally have other caches with other
>>transactional strategies?!
>>
>>Oliver
>>
>>snmvaughan92mailbox-slide@yahoo.com wrote:
>>
>>
>>>I'm working with 2.1b1, and have tracked down a
>>>structure corruption problem to the implementation
>>
>>of
>>
>>>the cache used by ExtendedStore. Since
>>
>>modifications
>>
>>>to store data are performed by retrieving a cloned
>>>copy, modifying the copy, and then storing the
>>>modified copy, it is very important that other
>>
>>threads
>>
>>>not be allowed to retrieve information from the
>>
>>cache
>>
>>>during this process. If two threads are updating
>>
>>the
>>
>>>same uri at the same time (i.e. modifying their
>>
>>own
>>
>>>copies), then only the last committed copy will be
>>>persisted.
>>>
>>>I can eliminate this problem by disabling the
>>
>>global
>>
>>>cache (using "isolation-shadow"). Of cource the
>>>performance hit for this configuration is fairly
>>
>>high.
>>
>>> Is there some plan to update the global cache?
>>>
>>>
>>
> ---------------------------------------------------------------------
>
>>>To unsubscribe, e-mail:
>>
>>slide-dev-unsubscribe@jakarta.apache.org
>>
>>>For additional commands, e-mail:
>>
>>slide-dev-help@jakarta.apache.org
>>
>>>
>>
>>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>slide-dev-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Andreas Probst <an...@gmx.net>.
Ah, I think I know what you're thinking about. Locking the
request uri isn't enough when using binding. Is there some kind
of "original" uri which could be used to identify a resource?
Andreas
On 8 Sep 2004 at 8:05, Oliver Zeigermann wrote:
> Hmmm, I see. Maybe we should use transient locks to achieve what you
> mentioned, then? And if we acquire all locks at the beginning of a
> transaction atomically there would be no possibility to run into
> deadlocks, right? How do we know just which resources to lock at the
> very beginning of the request?
>
> Oliver
>
> Andreas Probst wrote:
>
> > Hi Oliver,
> >
> > I think it would make sense to block the other thread just
> > before it starts the transaction until the first finishes it's
> > transaction.
> >
> > Do you remember the locking concept, which I explained some
> > weeks ago? It was meant to prevent database deadlocks but would
> > not work with the /history collection. There it would result in
> > a global lock.
> > Having exclusive and shared lock objects with reference to a
> > particular URI would prevent multiple threads changing the same
> > resource. However, another thread changing another resource
> > would not be blocked.
> >
> > I think it is not a cache issue, but an issue of the application
> > to prevent concurrent write access.
> >
> > What do you think?
> >
> > Andreas
> >
> > On 7 Sep 2004 at 23:30, Oliver Zeigermann wrote:
> >
> >
> >>As this must be a very common problem, does anyone know what other
> >>application servers, ORM tools do about the caching problem?
> >>
> >>I would be pretty interested...
> >>
> >>Oliver
> >>
> >>Oliver Zeigermann wrote:
> >>
> >>
> >>>This make sense for me, I understand now. Is there anything you could
> >>>propose? Would you opt for chaniging the caching mechanism?
> >>>
> >>>Oliver
> >>>
> >>>snmvaughan92mailbox-slide@yahoo.com wrote:
> >>>
> >>>
> >>>>The problem results from the fact that the node store
> >>>>includes a list of children.
> >>>>
> >>>>Start with a collection containing a single member
> >>>>resource {a}. Have two threads make changes to the
> >>>>collection, where one thread removes this child
> >>>>resource.
> >>>>
> >>>>Thread 1 reads {a}, adds "b" and then writes {a, b}.
> >>>>
> >>>>Thread 2 reads {a}, deletes "a", and then writes {}.
> >>>>
> >>>>Thread 1 Cache Thread 2
> >>>>-------- -------- --------
> >>>> {a} <- {a}
> >>>> {a} -> {a}
> >>>> {a, b} {}
> >>>> {} <- {}
> >>>> {a, b} -> {a, b}
> >>>>
> >>>>Since thread 1 finish last, the cache now contains an
> >>>>object which references a child "a" which does not
> >>>>exist. Since both threads intended to update the
> >>>>object, if the cache blocked during either
> >>>>transaction, then the resulting list of children would
> >>>>simply be {b}.
> >>>>
> >>>>--- Oliver Zeigermann <ol...@zeigermann.de> wrote:
> >>>>
> >>>>
> >>>>
> >>>>>I can not see how this may lead to corrupt data,
> >>>>>could you explain, please? What I can see is that it allows for lost
> >>>>>updates, which is bad enough, but a known issue.
> >>>>>
> >>>>>A solution might be to employ another mechanism to
> >>>>>guarantee more transactionality, but the existing has some very
> >>>>>nice featues:
> >>>>>
> >>>>>(1) It works - most important ;)
> >>>>>(2) It never blocks and never deadlocks
> >>>>>(3) A commit never fails for logical reasons
> >>>>>
> >>>>>If you have something that has similar features and
> >>>>>allows for better transactionlity, please submit it. Maybe it could be
> >>>>>an idea to optionally have other caches with other
> >>>>>transactional strategies?!
> >>>>>
> >>>>>Oliver
> >>>>>
> >>>>>snmvaughan92mailbox-slide@yahoo.com wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I'm working with 2.1b1, and have tracked down a
> >>>>>>structure corruption problem to the implementation
> >>>>>
> >>>>>
> >>>>>of
> >>>>>
> >>>>>
> >>>>>>the cache used by ExtendedStore. Since
> >>>>>
> >>>>>
> >>>>>modifications
> >>>>>
> >>>>>
> >>>>>>to store data are performed by retrieving a cloned
> >>>>>>copy, modifying the copy, and then storing the
> >>>>>>modified copy, it is very important that other
> >>>>>
> >>>>>
> >>>>>threads
> >>>>>
> >>>>>
> >>>>>>not be allowed to retrieve information from the
> >>>>>
> >>>>>
> >>>>>cache
> >>>>>
> >>>>>
> >>>>>>during this process. If two threads are updating
> >>>>>
> >>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>>same uri at the same time (i.e. modifying their
> >>>>>
> >>>>>
> >>>>>own
> >>>>>
> >>>>>
> >>>>>>copies), then only the last committed copy will be
> >>>>>>persisted.
> >>>>>>
> >>>>>>I can eliminate this problem by disabling the
> >>>>>
> >>>>>
> >>>>>global
> >>>>>
> >>>>>
> >>>>>>cache (using "isolation-shadow"). Of cource the
> >>>>>>performance hit for this configuration is fairly
> >>>>>
> >>>>>
> >>>>>high.
> >>>>>
> >>>>>
> >>>>>>Is there some plan to update the global cache?
> >>>>>>
> >>>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>
> >>>>
> >>>>>>To unsubscribe, e-mail:
> >>>>>
> >>>>>
> >>>>>slide-dev-unsubscribe@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>slide-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>
> >>>>
> >>>>>To unsubscribe, e-mail:
> >>>>>slide-dev-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail:
> >>>>>slide-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Hmmm, I see. Maybe we should use transient locks to achieve what you
mentioned, then? And if we acquire all locks at the beginning of a
transaction atomically there would be no possibility to run into
deadlocks, right? How do we know just which resources to lock at the
very beginning of the request?
Oliver
Andreas Probst wrote:
> Hi Oliver,
>
> I think it would make sense to block the other thread just
> before it starts the transaction until the first finishes it's
> transaction.
>
> Do you remember the locking concept, which I explained some
> weeks ago? It was meant to prevent database deadlocks but would
> not work with the /history collection. There it would result in
> a global lock.
> Having exclusive and shared lock objects with reference to a
> particular URI would prevent multiple threads changing the same
> resource. However, another thread changing another resource
> would not be blocked.
>
> I think it is not a cache issue, but an issue of the application
> to prevent concurrent write access.
>
> What do you think?
>
> Andreas
>
> On 7 Sep 2004 at 23:30, Oliver Zeigermann wrote:
>
>
>>As this must be a very common problem, does anyone know what other
>>application servers, ORM tools do about the caching problem?
>>
>>I would be pretty interested...
>>
>>Oliver
>>
>>Oliver Zeigermann wrote:
>>
>>
>>>This make sense for me, I understand now. Is there anything you could
>>>propose? Would you opt for chaniging the caching mechanism?
>>>
>>>Oliver
>>>
>>>snmvaughan92mailbox-slide@yahoo.com wrote:
>>>
>>>
>>>>The problem results from the fact that the node store
>>>>includes a list of children.
>>>>
>>>>Start with a collection containing a single member
>>>>resource {a}. Have two threads make changes to the
>>>>collection, where one thread removes this child
>>>>resource.
>>>>
>>>>Thread 1 reads {a}, adds "b" and then writes {a, b}.
>>>>
>>>>Thread 2 reads {a}, deletes "a", and then writes {}.
>>>>
>>>>Thread 1 Cache Thread 2
>>>>-------- -------- --------
>>>> {a} <- {a}
>>>> {a} -> {a}
>>>> {a, b} {}
>>>> {} <- {}
>>>> {a, b} -> {a, b}
>>>>
>>>>Since thread 1 finish last, the cache now contains an
>>>>object which references a child "a" which does not
>>>>exist. Since both threads intended to update the
>>>>object, if the cache blocked during either
>>>>transaction, then the resulting list of children would
>>>>simply be {b}.
>>>>
>>>>--- Oliver Zeigermann <ol...@zeigermann.de> wrote:
>>>>
>>>>
>>>>
>>>>>I can not see how this may lead to corrupt data,
>>>>>could you explain, please? What I can see is that it allows for lost
>>>>>updates, which is bad enough, but a known issue.
>>>>>
>>>>>A solution might be to employ another mechanism to
>>>>>guarantee more transactionality, but the existing has some very
>>>>>nice featues:
>>>>>
>>>>>(1) It works - most important ;)
>>>>>(2) It never blocks and never deadlocks
>>>>>(3) A commit never fails for logical reasons
>>>>>
>>>>>If you have something that has similar features and
>>>>>allows for better transactionlity, please submit it. Maybe it could be
>>>>>an idea to optionally have other caches with other
>>>>>transactional strategies?!
>>>>>
>>>>>Oliver
>>>>>
>>>>>snmvaughan92mailbox-slide@yahoo.com wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I'm working with 2.1b1, and have tracked down a
>>>>>>structure corruption problem to the implementation
>>>>>
>>>>>
>>>>>of
>>>>>
>>>>>
>>>>>>the cache used by ExtendedStore. Since
>>>>>
>>>>>
>>>>>modifications
>>>>>
>>>>>
>>>>>>to store data are performed by retrieving a cloned
>>>>>>copy, modifying the copy, and then storing the
>>>>>>modified copy, it is very important that other
>>>>>
>>>>>
>>>>>threads
>>>>>
>>>>>
>>>>>>not be allowed to retrieve information from the
>>>>>
>>>>>
>>>>>cache
>>>>>
>>>>>
>>>>>>during this process. If two threads are updating
>>>>>
>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>>same uri at the same time (i.e. modifying their
>>>>>
>>>>>
>>>>>own
>>>>>
>>>>>
>>>>>>copies), then only the last committed copy will be
>>>>>>persisted.
>>>>>>
>>>>>>I can eliminate this problem by disabling the
>>>>>
>>>>>
>>>>>global
>>>>>
>>>>>
>>>>>>cache (using "isolation-shadow"). Of cource the
>>>>>>performance hit for this configuration is fairly
>>>>>
>>>>>
>>>>>high.
>>>>>
>>>>>
>>>>>>Is there some plan to update the global cache?
>>>>>>
>>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>
>>>>
>>>>>>To unsubscribe, e-mail:
>>>>>
>>>>>
>>>>>slide-dev-unsubscribe@jakarta.apache.org
>>>>>
>>>>>
>>>>>>For additional commands, e-mail:
>>>>>
>>>>>
>>>>>slide-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>
>>>>
>>>>>To unsubscribe, e-mail:
>>>>>slide-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
>>>>>slide-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Andreas Probst <an...@gmx.net>.
Hi Oliver,
I think it would make sense to block the other thread just
before it starts the transaction until the first finishes it's
transaction.
Do you remember the locking concept, which I explained some
weeks ago? It was meant to prevent database deadlocks but would
not work with the /history collection. There it would result in
a global lock.
Having exclusive and shared lock objects with reference to a
particular URI would prevent multiple threads changing the same
resource. However, another thread changing another resource
would not be blocked.
I think it is not a cache issue, but an issue of the application
to prevent concurrent write access.
What do you think?
Andreas
On 7 Sep 2004 at 23:30, Oliver Zeigermann wrote:
> As this must be a very common problem, does anyone know what other
> application servers, ORM tools do about the caching problem?
>
> I would be pretty interested...
>
> Oliver
>
> Oliver Zeigermann wrote:
>
> > This make sense for me, I understand now. Is there anything you could
> > propose? Would you opt for chaniging the caching mechanism?
> >
> > Oliver
> >
> > snmvaughan92mailbox-slide@yahoo.com wrote:
> >
> >> The problem results from the fact that the node store
> >> includes a list of children.
> >>
> >> Start with a collection containing a single member
> >> resource {a}. Have two threads make changes to the
> >> collection, where one thread removes this child
> >> resource.
> >>
> >> Thread 1 reads {a}, adds "b" and then writes {a, b}.
> >>
> >> Thread 2 reads {a}, deletes "a", and then writes {}.
> >>
> >> Thread 1 Cache Thread 2
> >> -------- -------- --------
> >> {a} <- {a}
> >> {a} -> {a}
> >> {a, b} {}
> >> {} <- {}
> >> {a, b} -> {a, b}
> >>
> >> Since thread 1 finish last, the cache now contains an
> >> object which references a child "a" which does not
> >> exist. Since both threads intended to update the
> >> object, if the cache blocked during either
> >> transaction, then the resulting list of children would
> >> simply be {b}.
> >>
> >> --- Oliver Zeigermann <ol...@zeigermann.de> wrote:
> >>
> >>
> >>> I can not see how this may lead to corrupt data,
> >>> could you explain, please? What I can see is that it allows for lost
> >>> updates, which is bad enough, but a known issue.
> >>>
> >>> A solution might be to employ another mechanism to
> >>> guarantee more transactionality, but the existing has some very
> >>> nice featues:
> >>>
> >>> (1) It works - most important ;)
> >>> (2) It never blocks and never deadlocks
> >>> (3) A commit never fails for logical reasons
> >>>
> >>> If you have something that has similar features and
> >>> allows for better transactionlity, please submit it. Maybe it could be
> >>> an idea to optionally have other caches with other
> >>> transactional strategies?!
> >>>
> >>> Oliver
> >>>
> >>> snmvaughan92mailbox-slide@yahoo.com wrote:
> >>>
> >>>
> >>>> I'm working with 2.1b1, and have tracked down a
> >>>> structure corruption problem to the implementation
> >>>
> >>>
> >>> of
> >>>
> >>>> the cache used by ExtendedStore. Since
> >>>
> >>>
> >>> modifications
> >>>
> >>>> to store data are performed by retrieving a cloned
> >>>> copy, modifying the copy, and then storing the
> >>>> modified copy, it is very important that other
> >>>
> >>>
> >>> threads
> >>>
> >>>> not be allowed to retrieve information from the
> >>>
> >>>
> >>> cache
> >>>
> >>>> during this process. If two threads are updating
> >>>
> >>>
> >>> the
> >>>
> >>>> same uri at the same time (i.e. modifying their
> >>>
> >>>
> >>> own
> >>>
> >>>> copies), then only the last committed copy will be
> >>>> persisted.
> >>>>
> >>>> I can eliminate this problem by disabling the
> >>>
> >>>
> >>> global
> >>>
> >>>> cache (using "isolation-shadow"). Of cource the
> >>>> performance hit for this configuration is fairly
> >>>
> >>>
> >>> high.
> >>>
> >>>> Is there some plan to update the global cache?
> >>>>
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >>
> >>>> To unsubscribe, e-mail:
> >>>
> >>>
> >>> slide-dev-unsubscribe@jakarta.apache.org
> >>>
> >>>> For additional commands, e-mail:
> >>>
> >>>
> >>> slide-dev-help@jakarta.apache.org
> >>>
> >>>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >>
> >>> To unsubscribe, e-mail:
> >>> slide-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >>> slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
As this must be a very common problem, does anyone know what other
application servers, ORM tools do about the caching problem?
I would be pretty interested...
Oliver
Oliver Zeigermann wrote:
> This make sense for me, I understand now. Is there anything you could
> propose? Would you opt for chaniging the caching mechanism?
>
> Oliver
>
> snmvaughan92mailbox-slide@yahoo.com wrote:
>
>> The problem results from the fact that the node store
>> includes a list of children.
>>
>> Start with a collection containing a single member
>> resource {a}. Have two threads make changes to the
>> collection, where one thread removes this child
>> resource.
>>
>> Thread 1 reads {a}, adds "b" and then writes {a, b}.
>>
>> Thread 2 reads {a}, deletes "a", and then writes {}.
>>
>> Thread 1 Cache Thread 2
>> -------- -------- --------
>> {a} <- {a}
>> {a} -> {a}
>> {a, b} {}
>> {} <- {}
>> {a, b} -> {a, b}
>>
>> Since thread 1 finish last, the cache now contains an
>> object which references a child "a" which does not
>> exist. Since both threads intended to update the
>> object, if the cache blocked during either
>> transaction, then the resulting list of children would
>> simply be {b}.
>>
>> --- Oliver Zeigermann <ol...@zeigermann.de> wrote:
>>
>>
>>> I can not see how this may lead to corrupt data,
>>> could you explain, please? What I can see is that it allows for lost
>>> updates, which is bad enough, but a known issue.
>>>
>>> A solution might be to employ another mechanism to
>>> guarantee more transactionality, but the existing has some very
>>> nice featues:
>>>
>>> (1) It works - most important ;)
>>> (2) It never blocks and never deadlocks
>>> (3) A commit never fails for logical reasons
>>>
>>> If you have something that has similar features and
>>> allows for better transactionlity, please submit it. Maybe it could be
>>> an idea to optionally have other caches with other
>>> transactional strategies?!
>>>
>>> Oliver
>>>
>>> snmvaughan92mailbox-slide@yahoo.com wrote:
>>>
>>>
>>>> I'm working with 2.1b1, and have tracked down a
>>>> structure corruption problem to the implementation
>>>
>>>
>>> of
>>>
>>>> the cache used by ExtendedStore. Since
>>>
>>>
>>> modifications
>>>
>>>> to store data are performed by retrieving a cloned
>>>> copy, modifying the copy, and then storing the
>>>> modified copy, it is very important that other
>>>
>>>
>>> threads
>>>
>>>> not be allowed to retrieve information from the
>>>
>>>
>>> cache
>>>
>>>> during this process. If two threads are updating
>>>
>>>
>>> the
>>>
>>>> same uri at the same time (i.e. modifying their
>>>
>>>
>>> own
>>>
>>>> copies), then only the last committed copy will be
>>>> persisted.
>>>>
>>>> I can eliminate this problem by disabling the
>>>
>>>
>>> global
>>>
>>>> cache (using "isolation-shadow"). Of cource the
>>>> performance hit for this configuration is fairly
>>>
>>>
>>> high.
>>>
>>>> Is there some plan to update the global cache?
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail:
>>>
>>>
>>> slide-dev-unsubscribe@jakarta.apache.org
>>>
>>>> For additional commands, e-mail:
>>>
>>>
>>> slide-dev-help@jakarta.apache.org
>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail:
>>> slide-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
This make sense for me, I understand now. Is there anything you could
propose? Would you opt for chaniging the caching mechanism?
Oliver
snmvaughan92mailbox-slide@yahoo.com wrote:
> The problem results from the fact that the node store
> includes a list of children.
>
> Start with a collection containing a single member
> resource {a}. Have two threads make changes to the
> collection, where one thread removes this child
> resource.
>
> Thread 1 reads {a}, adds "b" and then writes {a, b}.
>
> Thread 2 reads {a}, deletes "a", and then writes {}.
>
> Thread 1 Cache Thread 2
> -------- -------- --------
> {a} <- {a}
> {a} -> {a}
> {a, b} {}
> {} <- {}
> {a, b} -> {a, b}
>
> Since thread 1 finish last, the cache now contains an
> object which references a child "a" which does not
> exist. Since both threads intended to update the
> object, if the cache blocked during either
> transaction, then the resulting list of children would
> simply be {b}.
>
> --- Oliver Zeigermann <ol...@zeigermann.de> wrote:
>
>
>>I can not see how this may lead to corrupt data,
>>could you explain,
>>please? What I can see is that it allows for lost
>>updates, which is bad
>>enough, but a known issue.
>>
>>A solution might be to employ another mechanism to
>>guarantee more
>>transactionality, but the existing has some very
>>nice featues:
>>
>>(1) It works - most important ;)
>>(2) It never blocks and never deadlocks
>>(3) A commit never fails for logical reasons
>>
>>If you have something that has similar features and
>>allows for better
>>transactionlity, please submit it. Maybe it could be
>>an idea to
>>optionally have other caches with other
>>transactional strategies?!
>>
>>Oliver
>>
>>snmvaughan92mailbox-slide@yahoo.com wrote:
>>
>>
>>>I'm working with 2.1b1, and have tracked down a
>>>structure corruption problem to the implementation
>>
>>of
>>
>>>the cache used by ExtendedStore. Since
>>
>>modifications
>>
>>>to store data are performed by retrieving a cloned
>>>copy, modifying the copy, and then storing the
>>>modified copy, it is very important that other
>>
>>threads
>>
>>>not be allowed to retrieve information from the
>>
>>cache
>>
>>>during this process. If two threads are updating
>>
>>the
>>
>>>same uri at the same time (i.e. modifying their
>>
>>own
>>
>>>copies), then only the last committed copy will be
>>>persisted.
>>>
>>>I can eliminate this problem by disabling the
>>
>>global
>>
>>>cache (using "isolation-shadow"). Of cource the
>>>performance hit for this configuration is fairly
>>
>>high.
>>
>>> Is there some plan to update the global cache?
>>>
>>>
>>
> ---------------------------------------------------------------------
>
>>>To unsubscribe, e-mail:
>>
>>slide-dev-unsubscribe@jakarta.apache.org
>>
>>>For additional commands, e-mail:
>>
>>slide-dev-help@jakarta.apache.org
>>
>>>
>>
>>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>slide-dev-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Full caching allows corruption
Posted by sn...@yahoo.com.
The problem results from the fact that the node store
includes a list of children.
Start with a collection containing a single member
resource {a}. Have two threads make changes to the
collection, where one thread removes this child
resource.
Thread 1 reads {a}, adds "b" and then writes {a, b}.
Thread 2 reads {a}, deletes "a", and then writes {}.
Thread 1 Cache Thread 2
-------- -------- --------
{a} <- {a}
{a} -> {a}
{a, b} {}
{} <- {}
{a, b} -> {a, b}
Since thread 1 finish last, the cache now contains an
object which references a child "a" which does not
exist. Since both threads intended to update the
object, if the cache blocked during either
transaction, then the resulting list of children would
simply be {b}.
--- Oliver Zeigermann <ol...@zeigermann.de> wrote:
> I can not see how this may lead to corrupt data,
> could you explain,
> please? What I can see is that it allows for lost
> updates, which is bad
> enough, but a known issue.
>
> A solution might be to employ another mechanism to
> guarantee more
> transactionality, but the existing has some very
> nice featues:
>
> (1) It works - most important ;)
> (2) It never blocks and never deadlocks
> (3) A commit never fails for logical reasons
>
> If you have something that has similar features and
> allows for better
> transactionlity, please submit it. Maybe it could be
> an idea to
> optionally have other caches with other
> transactional strategies?!
>
> Oliver
>
> snmvaughan92mailbox-slide@yahoo.com wrote:
>
> > I'm working with 2.1b1, and have tracked down a
> > structure corruption problem to the implementation
> of
> > the cache used by ExtendedStore. Since
> modifications
> > to store data are performed by retrieving a cloned
> > copy, modifying the copy, and then storing the
> > modified copy, it is very important that other
> threads
> > not be allowed to retrieve information from the
> cache
> > during this process. If two threads are updating
> the
> > same uri at the same time (i.e. modifying their
> own
> > copies), then only the last committed copy will be
> > persisted.
> >
> > I can eliminate this problem by disabling the
> global
> > cache (using "isolation-shadow"). Of cource the
> > performance hit for this configuration is fairly
> high.
> > Is there some plan to update the global cache?
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> slide-dev-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org