Ah, I somehow did not understand you were talking about external
transactions. This is just bad luck. Nothing you can do, but repeat
the external transaction. IMHO this will not change in 2.2 or in any
other release as there is no way to avoid it. Of course there must not
be any Slide locks when having an external transaction (see next
post).
Oliver
On Wed, 15 Dec 2004 17:38:30 -0800, Warwick Burrows
<[EMAIL PROTECTED]> wrote:
>
> Sorry, I should have been clearer. I have the same problem with full mode as
> without it (ie. write sequential mode).
>
> And its no wonder since the global locks used to implement it aren't used
> when an external transaction is active. Eg. from AbstractWebdavMethod.java:
>
> if (!slideToken.isExternalTransaction()) {
> token.begin();
> transactionIsStarted = true;
> if (txForAllRequests()) {
> slideToken.setForceStoreEnlistment(true);
> }
>
> if (this instanceof ReadMethod) {
> assureGlobalReadLock();
> } else if (this instanceof WriteMethod) {
> assureGlobalWriteLock();
> }
> globalLockObtained = true;
> }
>
> I tried taking the lock piece outside of this condition but the server
> deadlocks.
>
> Warwick
>
>
> > -----Original Message-----
> > From: Warwick Burrows [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 15, 2004 7:27 PM
> > To: 'Slide Developers Mailing List'
> > Subject: RE: New feature for internally repeating conflicting requests
> >
> >
> >
> > Nope. Unfortunately that doesn't work either.
> >
> >
> > > -----Original Message-----
> > > From: Warwick Burrows [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, December 15, 2004 7:23 PM
> > > To: 'Slide Developers Mailing List'
> > > Subject: RE: New feature for internally repeating
> > conflicting requests
> > >
> > >
> > >
> > > Ok. I'll try that.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, December 15, 2004 7:04 PM
> > > > To: Slide Developers Mailing List
> > > > Subject: Re: New feature for internally repeating
> > > conflicting requests
> > > >
> > > >
> > > > It should not deadlock when you have sequential-mode as "full"
> > > > turned on. That's the way to go for 2.1...
> > > >
> > > > Oliver
> > > >
> > > >
> > > > On Wed, 15 Dec 2004 13:34:22 -0800, Warwick Burrows
> > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I agree with you about new features and 2.1. Unfortunately
> > > > my company
> > > > > can't go into QA or production with -911 errors failing our
> > > > > transactions so I will just have to keep any changes I
> > > make to fix
> > > > > this problem with 2.1 in my own sandbox and won't submit
> > > them back
> > > > > unless they apply to the HEAD. Then I will have to wait
> > until 2.2
> > > > > before I can sync my tree up with CVS again. And if that's
> > > > the way it
> > > > > has to be then I'm fine with that.
> > > > >
> > > > > My concern is that the Slide 2.1 release is not
> > suitable for any
> > > > > scenarios where load is important while this problem is
> > > > outstanding in
> > > > > the 2.1 tree. Though I agree your solution is a feature, it
> > > > could also
> > > > > be considered as a bug fix since Slide returns a 500
> > error when it
> > > > > gets this exception and applications don't have a way to
> > > deal with
> > > > > that.
> > > > >
> > > > > Warwick
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Wednesday, December 15, 2004 10:59 AM
> > > > > > To: Slide Developers Mailing List
> > > > > > Subject: Re: New feature for internally repeating conflicting
> > > > > > requests
> > > > > >
> > > > > >
> > > > > > On Wed, 15 Dec 2004 17:07:26 +0100, Oliver Zeigermann
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > On Wed, 15 Dec 2004 16:55:58 +0100, Oliver Zeigermann
> > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > > On Tue, 14 Dec 2004 17:52:02 -0800, Warwick Burrows
> > > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > > A real problem is that the
> > > ConcurrencyConflictException
> > > > > > > > > > doesn't make
> > > > > > > > > > > it past LockMethod when it bubbles up from
> > > the store. In
> > > > > > > > > > > LockMethod its caught in a generic Exception
> > > > catch block at
> > > > > > > > > > > line 368 and converted into a WebdavException. This
> > > > > > may happen
> > > > > > > > > > > in other methods too. Had you looked at all
> > > > > > > > > >
> > > > > > > > > > Have you considered this:
> > > > > > > > > >
> > > > > > > > > > public class ConcurrencyConflictException extends
> > > > > > > > > > /*
> > > > > > > > > > * XXX: this must be an error to ensure it
> > > > > > gets caught
> > > > > > > > > > in the webdav
> > > > > > > > > > * layer only
> > > > > > > > > > */Error {
> > > > > > > > > >
> > > > > > > > > > Line 368 catches an Exception, not an Error, that's
> > > > > > the trick ;)
> > > > > > > > >
> > > > > > > > > And it would be great except that
> > > > AbstractStore.java catches
> > > > > > > > > "throwables" including Errors and is wrapping the Error
> > > > > > inside a
> > > > > > > > > ServiceAccessException which is then thrown back to
> > > > > > > > > LockMethod.
> > > > > > > >
> > > > > > > > Argh! You are right! I was only provoking to throw this
> > > > > > > > exception from the core. I'd say the problem is in
> > > > > > > > AbstractStore,
> > > > > > it certainly
> > > > > > > > should not catch errors...
> > > > > > > >
> > > > > > > > > I need to fix this concurrency issue in Slide
> > so we can go
> > > > > > > > > into our QA load test phase next week :-) I was
> > > trying to
> > > > > > > > > work back from the changes you had made to
> > > > > > > > > AbstractWebdavMethod
> > > > > > and the db
> > > > > > > > > stores for this retry feature but really need a list of
> > > > > > the files
> > > > > > > > > you changed so I can merge them back into our 2.1
> > > > > > source tree. I
> > > > > > > > > don't have the submission logs for the defects you
> > > > > > submitted for
> > > > > > > > > this feature.
> > > > > > > >
> > > > > > > > We not go for CVS head then?
> > > > > > >
> > > > > > > One more reason for you to stick to the CVS head for new
> > > > > > features is
> > > > > > > shown by this issue. There will be no support for this
> > > > > > retry feature
> > > > > > > in 2.1 and it isn't even alpha, yet (as we have seen).
> > > > It needs to
> > > > > > > evolve and mature with a full 2.2 release cycle.
> > > > > >
> > > > > > Still another example of the worth of community based open
> > > > > > development. I implement a new feature in the open, others
> > > > > > contribute like you and finally it gets going. So, do
> > > not create
> > > > > > your own branch...
> > > > > >
> > > > > > Oliver
> > > > > >
> > > > > >
> > > >
> > --------------------------------------------------------------------
> > > > > > -
> > > > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
