We have not tested that scenario as we are not adding users or those class of items on the fly, we have just tested file/folder consistency. I can imagine some of those at startup items might be an issue.
rgds CB ----- Original Message ----- From: "GARTRELL,MIKE (HP-Corvallis,ex1)" <[EMAIL PROTECTED]> To: "'Slide Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, August 02, 2002 1:14 PM Subject: RE: Slide caching/data consistency issues > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
