You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by "GARTRELL,MIKE (HP-Corvallis,ex1)" <mi...@hp.com> on 2002/08/02 01:23:42 UTC
Slide caching/data consistency issues
What data is cached internally within Slide when using the
J2EEDescriptorsSore/JDBCDescriptorsStore? What kinds of data consistency
issues will arise if multiple Slide instances are deployed against a single
database?
---> Mike Gartrell <--- ---> mike_gartrell@hp.com <---
---> phone: (541) 715-0008 <---
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Slide caching/data consistency issues
Posted by Michael Smith <ms...@xn.com.au>.
"GARTRELL,MIKE (HP-Corvallis,ex1)" wrote:
>
> What data is cached internally within Slide when using the
> J2EEDescriptorsSore/JDBCDescriptorsStore? What kinds of data consistency
> issues will arise if multiple Slide instances are deployed against a single
> database?
Slide will cache pretty much everything from the descriptors store (not
the content store, though). Data consistency will not be maintained (and
will fail quickly and badly) if you use multiple slide instances against
a common database. This is easily solved by a small change to make slide
_not_ cache stuff internally, but that has dire performance implications
(it goes from slow with caching to completely unusable without).
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Slide caching/data consistency issues
Posted by Christopher Lenz <cm...@gmx.de>.
Colin Britton wrote:
> I am hoping this email both clears up any confusion and provokes a committer
> to pick up this and enable us to all work on a better single J2EE approach.
Ok, I'll pick it up then ;o)
Ashok, can you post the latest version of the stores? It'd be great if
you could provide some how-to docs as well (plain old ASCII would suffice).
What dbms's has the schema been tested against? It will need to work
with HSQLDB, as that is included in the distro.
I'm wondering if the new stores should just replace the current J2EE
stores, instead of having 2 versions. The J2EE stores have not seen a
formal release yet, anyway.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Slide caching/data consistency issues
Posted by Colin Britton <cb...@metatomix.com>.
With the J2EE stores there are a some key things to note.
1) There are two possible versions, the current CVS version and the
"proposed" version J2EEDescriptors/ContentStore2. The latter was proposed by
Ashok Kumar to improve performance (which it does) and has other
improvements.
2) The J2EE stores REQUIRE an XA datasource, this is because the slide
transactions are across multiple database transactions. If you don't use an
XA datasource then stores will appear to work, but conflicts and database
contention can (and will) occur.
3) The JDBC stores are NOT multi-user. They only allow a single user to
access a store at a time (more or less a waste of time for most uses!)
The "proposed" J2EEDescriptors/ContentStore2 implementation provides a more
scalable and better core performance implementation of the db store. we
still feel it has more to give, but it already offers a significant
improvement. It is the only version we have been using for a while and
Ashoks work has just been on this. It also has a compression feature, which
can be turned on to zip the xml content. This is good for most medium to
large xml files and the 'cost' of zipping the stream is a lot less than the
blob transfer speeds, as well as reducing table size.
The J2EEDescriptors/ContentStore2 has yet to be picked up by a committer and
added to cvs, I can only guess it is not important to their needs and
therefore not given the time required for understanding, validating and
committing the code. We will continue to post updates to it on the list.
I will leave the "what is cached" issue for Ashok to answer, as he is more
aware of the details, but as to issues with multiple slides on a single DB
that is the configuration that we run most of the time. We are running on
SQLserver and IBM DB2 UDB most of the time and we are using both the content
store and descriptor store.
We have ran significant tests on multi-user/single-file and
multi-user/multi-file load tests and no longer see any issues with corrupt
databases or contention.
I am hoping this email both clears up any confusion and provokes a committer
to pick up this and enable us to all work on a better single J2EE approach.
rgds
CB
----- Original Message -----
From: "GARTRELL,MIKE (HP-Corvallis,ex1)" <mi...@hp.com>
To: <sl...@jakarta.apache.org>
Sent: Thursday, August 01, 2002 7:23 PM
Subject: Slide caching/data consistency issues
> What data is cached internally within Slide when using the
> J2EEDescriptorsSore/JDBCDescriptorsStore? What kinds of data consistency
> issues will arise if multiple Slide instances are deployed against a
single
> database?
>
> ---> Mike Gartrell <--- ---> mike_gartrell@hp.com <---
> ---> phone: (541) 715-0008 <---
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Slide caching/data consistency issues
Posted by Colin Britton <cb...@metatomix.com>.
With the J2EE stores there are a some key things to note.
1) There are two possible versions, the current CVS version and the
"proposed" version J2EEDescriptors/ContentStore2. The latter was proposed by
Ashok Kumar to improve performance (which it does) and has other
improvements.
2) The J2EE stores REQUIRE an XA datasource, this is because the slide
transactions are across multiple database transactions. If you don't use an
XA datasource then stores will appear to work, but conflicts and database
contention can (and will) occur.
3) The JDBC stores are NOT multi-user. They only allow a single user to
access a store at a time (more or less a waste of time for most uses!)
The "proposed" J2EEDescriptors/ContentStore2 implementation provides a more
scalable and better core performance implementation of the db store. we
still feel it has more to give, but it already offers a significant
improvement. It is the only version we have been using for a while and
Ashoks work has just been on this. It also has a compression feature, which
can be turned on to zip the xml content. This is good for most medium to
large xml files and the 'cost' of zipping the stream is a lot less than the
blob transfer speeds, as well as reducing table size.
The J2EEDescriptors/ContentStore2 has yet to be picked up by a committer and
added to cvs, I can only guess it is not important to their needs and
therefore not given the time required for understanding, validating and
committing the code. We will continue to post updates to it on the list.
I will leave the "what is cached" issue for Ashok to answer, as he is more
aware of the details, but as to issues with multiple slides on a single DB
that is the configuration that we run most of the time. We are running on
SQLserver and IBM DB2 UDB most of the time and we are using both the content
store and descriptor store.
We have ran significant tests on multi-user/single-file and
multi-user/multi-file load tests and no longer see any issues with corrupt
databases or contention.
I am hoping this email both clears up any confusion and provokes a committer
to pick up this and enable us to all work on a better single J2EE approach.
rgds
CB
----- Original Message -----
From: "GARTRELL,MIKE (HP-Corvallis,ex1)" <mi...@hp.com>
To: <sl...@jakarta.apache.org>
Sent: Thursday, August 01, 2002 7:23 PM
Subject: Slide caching/data consistency issues
> What data is cached internally within Slide when using the
> J2EEDescriptorsSore/JDBCDescriptorsStore? What kinds of data consistency
> issues will arise if multiple Slide instances are deployed against a
single
> database?
>
> ---> Mike Gartrell <--- ---> mike_gartrell@hp.com <---
> ---> phone: (541) 715-0008 <---
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>