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]>
