>> The default 2.1 distribution will not have any deadlock problems.
However, at the cost of a single write request at a time.

I guess serializing writes is a result of the global lock you talk about
implementing in the original "Concurrent upload error: Status Quo" thread.
Would you mind explaining the problem to us so that we can also understand
the reasoning behind serializing writes. I'm guessing its because the
history directory is the choke point.

I ask because our Slide client uses its own authorization and doesn't use
Slide security so we have turned it off. It also doesn't need
auto-versioning because the client will handle file versioning explicitly.
So if I enable all four of the workarounds you had mentioned to avoid
deadlocks then can I turn off the global write lock in the 2.1 beta and
increase my write-speed?

Thanks,
Warwick


-----------------------------------------------------------
 Warwick Burrows              E2open
 Senior Engineer              9600 Great Hills Trail, #325
 http://www.e2open.com        Austin TX 78759
-----------------------------------------------------------


-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 03, 2004 6:08 AM
To: Slide Users Mailing List
Subject: Re: Concurrent upload error: Status Quo


It is. At least I think so as I have spent many hours on it without 
finally fixing it. As explained in other threads the main problem is the 
history folder and the way security works. I will spend more work in it 
for the 2.2 release. I will try to fix the security problem by not 
calculating security informations all the time, but by remembering 
effective ones. I will have to think about the history folder problem. 
Maybe some sort of virtual resource mapped into the history folder. But 
this may be nonsense just as well.

Oliver


Carlos Villegas wrote:

> Oliver Zeigermann wrote:
> 
>> Hi Warwick!
>>
>> Your summary is excellent. The default 2.1 distribution will not have
>> any deadlock problems. However, at the cost of a single write request 
>> at a time.
>>
>> Oliver
>>
> Is it very difficult or time consuming to avoid that limitation?
> 
> Carlos
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to