We have found that Slide does internal caching of some resources,
such as users. If two or more instances of Slide are deployed against the
same DB, there are data consistency issues due to internal caching in Slide.
For example, if a new user is added to one Slide instance, that new user
will not be visible to the second Slide instance without a restart of the
server. Have you observed these problems or developed a fix for them?
-----Original Message-----
From: Kumar, Ashok [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 02, 2002 6:32 AM
To: Slide Users Mailing List
Subject: RE: Slide caching/data consistency issues
About the caching done with respect to J2EEStore2:
In slide, data revolves round the root entity which is an URI. All the user
info, premisssion are all translated as URIs(from domain.xml). Therefore in
the database schemas URI becomes the different table connectors. Now in the
new database schema all the URI's go into a single table URI table where the
corresponding Uri_id is also stored. And for all the other table relations
this uri_id becomes a part of the foreign key.
Now if we look at the various operations in slide it always does
verifications with respect to the user, the role and permissions and the
root nodes(all in URI string form). This means that in the new schema we
will always be forced to get the corresponding uri_id for the respective
uri_string for all the operations, which will result in repeated access to
the same basic data to the URI table. Also over a period of time this URI
table gets very big. To avoid the performance overhead we have implemented a
hashmap based caching to act as a intermediate lookup for URI_id and also
for URI_String This will be for each store implementation,ie for a pair of
contentStore ,Descriptorstore. There for if we look at J2EEStore2, this is
an extension of J2EEStore just with these hashmap implementations.
Therefore any request for an URI_ID or URIString will be looked for in this
cache and if not present is fetched from the table and subsequently cached
too. As to strike a balance we have fixed the cache size to 2000 the level
once reached, cache is flushed. This is just to make sure that cache doesnot
affect the overall memory used.
In our scenario of implementation:
We are having 2 slide deployments as 2 different webapps, but both pointing
to the same database for the content/descriptor store. Also both the stores
are being loaded with documents simultaneously. So far it is very stable in
our setup. (Note:We have not turned on any versioning so far). As Colin
pointed out earlier all this consistancy is pivoting around have a true
XADatasource implementation.
Before the XADatasource implementaion, we tried multithreaded processes
putting in umpteen number of documents in the same location and this used to
having tables getting locked. Also with the new schema we ended up having
forieng key violations in the absence of XADatasource. So far we have tested
this with JSQLConnect 2.7 and Tyrex1.0. Not yet tested on the
JakartaCommonsDBCP pools.
I will post the latest source codes in a subsequent mail.
Ashok
-----Original Message-----
From: Britton, Colin
Sent: Thursday, August 01, 2002 9:29 PM
To: Slide Users Mailing List
Subject: Re: Slide caching/data consistency issues
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)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 <--- ---> [EMAIL PROTECTED] <---
> ---> phone: (541) 715-0008 <---
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
