Domain.xml - what is 'sequential-mode'?

In domain.xml, configuration node, what is this
configuration option
used/useful for?

<!-- Can be "off", "fine-grain",
"write" and "full" -->
<parameter
name="sequential-mode">fine-grain</paramet
er>

Specifically in regards to optimizing for search/read
performance while
still maintaining write-integrity.

Thanks,
-D

------------------------------------------------------------
---------
To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
For additional commands, e-mail: slide-user-helpjakarta.apache.org

This should be explained here:

http://wiki.apache.org/jakarta-slide/ConcurrencyIssues

Oliver

2006/7/20, Darren Hartford <dhartfordghsinc.com>:
> In domain.xml, configuration node, what is this
configuration option
> used/useful for?
>
> <!-- Can be "off",
"fine-grain", "write" and
"full" -->
> <parameter
name="sequential-mode">fine-grain</paramet
er>
>
> Specifically in regards to optimizing for search/read
performance while
> still maintaining write-integrity.
>
> Thanks,
> -D
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
> For additional commands, e-mail: slide-user-helpjakarta.apache.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
For additional commands, e-mail: slide-user-helpjakarta.apache.org

Hey Oliver,

what problems could I run into if I use sequential-mode =
OFF ?

We're running webapplications on Slide with various
databases and  
today we are using "WRITE" mode but I find it
bothersome that a whole  
folder is locked for read access when a long write is
happening to  
one of its files.

Does fine-grained work better?

For example a webapp we created automatically gets RSS feeds
and  
stores them in Slide every 20 minutes. The frontpage of the
webapp  
then tries to read these files via an Ajax RSS reader and
has to wait  
until the writes are finished. I would much rather (if
versions are  
enabled) that while the PUT is going on the GET would get
the last  
version available but otherwise wait until the PUT is done
and only  
that resource gets locked up for the moment. Is that
possible today?

And the last question...when will the next stable version of
Slide be  
released?

best regards

Eiki, idega.


רררררררררררררררררררררררררררררררררררררררררררררררררררררררררררר
רררררררררררר 
רררררררררררררררררררררררררררררררררררררררררררררררררררררררררררר
Eirikur S. Hrafnsson
Chief Software Engineer

eikiidega.is


רררררררררררררררררררררררררררררררררררררררררררררררררררררררררררר
רררררררררררר 
רררררררררררררררררררררררררררררררררררררררררררררררררררררררררררר
Idega hf.  ץ  Engjavegi 6  ץ  104 Reykjav’k  ץ  Iceland
Tel. +354 554 7557  ץ  Fax +354 885 7557

http://www.idega.com  ץ 
idegaidega.com





On 20.7.2006, at 20:35, Oliver Zeigermann wrote:

> This should be explained here:
>
> http://wiki.apache.org/jakarta-slide/ConcurrencyIssues
>
> Oliver
>
> 2006/7/20, Darren Hartford <dhartfordghsinc.com>:
>> In domain.xml, configuration node, what is this
configuration option
>> used/useful for?
>>
>> <!-- Can be "off",
"fine-grain", "write" and
"full" -->
>> <parameter
name="sequential-mode">fine-grain</paramet
er>
>>
>> Specifically in regards to optimizing for
search/read performance  
>> while
>> still maintaining write-integrity.
>>
>> Thanks,
>> -D
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
>> For additional commands, e-mail:
slide-user-helpjakarta.apache.org
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
> For additional commands, e-mail: slide-user-helpjakarta.apache.org
>

Hey, Eirikur

2006/7/21, Eirikur Hrafnsson <eikiidega.is>:
> what problems could I run into if I use sequential-mode
= OFF ?

This completely disables Slide's internal locking. It might
cause some
weired concurrency errors as Slide's internal cache only
supports an
isolation level similar to read committed. If you set your
databases
isolation level to read committed as well this should be
more
consistent. However, this isolation level might not be
appropritate to
what you do.

Another secure solution would be to switch off caching and
set
database isolation to serializable. The performance penalty
is
disastrous, though.

> We're running webapplications on Slide with various
databases and today we
> are using "WRITE" mode but I find it
bothersome that a whole folder is
> locked for read access when a long write is happening
to one of its files.
>
> Does fine-grained work better?

Fine grain locking only locks those folders that are
actually
concerned by an action. This may lead to some form of - very
hard to
explain - distributed deadlock, though. Depending on your
database and
then again isolation level.

An alternative is the option to retry upon conflict. This
comes at a
general performance penalty, but may be a good option.

More details at

http://wiki.apache.org/jakarta-slide/ConcurrencyIssues

> For example a webapp we created automatically gets RSS
feeds and stores them
> in Slide every 20 minutes. The frontpage of the webapp
then tries to read
> these files via an Ajax RSS reader and has to wait
until the writes are
> finished. I would much rather (if versions are enabled)
that while the PUT
> is going on the GET would get the last version
available but otherwise wait
> until the PUT is done and only that resource gets
locked up for the moment.
> Is that possible today?

Might work if you upload to a diffrent file name and later
move it to
the desired one. Move generally should be be faster than
put.

> And the last question...when will the next stable
version of Slide be
> released?

Don't ask me. I have no idea.

Cheers

Oliver

------------------------------------------------------------
---------
To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
For additional commands, e-mail: slide-user-helpjakarta.apache.org

2006/7/22, Oliver Zeigermann <oliver.zeigermanngmail.com>:
> > Does fine-grained work better?
>
> Fine grain locking only locks those folders that are
actually
> concerned by an action. This may lead to some form of -
very hard to
> explain - distributed deadlock, though. Depending on
your database and
> then again isolation level.

One addition: Theoretically, fine grain locking should work
fine when
all locking is done in the application, i.e. Slide. This can
either be
achieved by using an optimistic, non-blocking isolation
strategy (like
serializable with Oracle) or a very low one (read
uncommitted). I
haven't tried this practically, though, but might be worth
an
experiment.

Cheers

Oliver

------------------------------------------------------------
---------
To unsubscribe, e-mail: slide-user-unsubscribejakarta.apache.org
For additional commands, e-mail: slide-user-helpjakarta.apache.org