Hi There! Does the J2EEContentStore2 require the JDBCContentStore2 ?? I'd like to try it all out.
Some more questions regarding the discussion around data consistency, and multiple slide instances sharing a database: If 2 slide instances use the same database, the following is theoretically possible: User 1: PUT file f1.txt to collection /files/folder1/f1.txt User 2: MOVE /files/folder1 to /files/folder1withnewname What would happen in this cases? Is the behaviour deterministic? Does modifying a file 'lock' the tree above the file for changes? Is the saving of a node's descriptors and content done within the same database transaction? If not, even just one slide instance could develop conflicts (esp. if it crashes or loses database connection in the middle of saving). Thanks, Richie -----Urspr�ngliche Nachricht----- Von: Kumar, Ashok [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 02. August 2002 16:42 An: Slide Developers Mailing List Cc: Slide Users Mailing List Betreff: Latest J2EEStore2 based on the new Database Schema Hi Christopher, Here is the latest version of J2EEStore2 version based on the new database schema. Attached are the following J2EEStore2 J2EEContentStore2 J2EEDescriptor2 J2EEStore2 howto ( this is based on Tomcat 4.1.x implementation). the above stores can work on TC4.1.x based on original J2EEStore Howto. NewDatabase Schema (for SQLServer) MTXZip.java( used for the compression) Notes: 1.The schema attached is for SQLServer. A postgres version of the schema was submitted on 08.01.2002 by Jean. If i get time I will try to generate the schemas for the other databases including the HSQLDB. 2. I have incorporated a feature for compression of content before storage. See the MTXZip.java for the source. Advantages we could gain by having this feature are: 1. Performance and size issues. 2. Solved the issue of truncation of files while retrieval. The problem is as follows: Store a small size file say 10k. Now replace the same file with a larger size file say 95K. While storing the bigger file give a request for the file. It will return the new file but only upto 10K, not the 95K. The reason is new file size info is updated by the descriptor store only after the storage by the contentStore where as the content is fetched after reading the desicptor length info. Hence what happens is that while a 95 k file is being put the descriptor info is still 10k. So the GET request has length info 10K and it get the 95 K file from the contentstore (as soon as it gets committed) leading to 10K of the 95 K file causing truncation. The compression/decompression utility has access to the content length info which enable us to update the descriptor object as soon as the content is read for the length size which solves the issue. The relevant code can be seen in J2EEContentStore2. + 93 import com.metatomix.commons.util.MTXZip; // Document Compression + 106 private boolean bcompress = false; + 122 bcompress = (((String)parameters.get("compress")).equals("true"))? true:false; + 171 if (bcompress) { + 172 getLogger().log("DeCompressing the data",LOG_CHANNEL,Logger.INFO); + 173 MTXZip mtxzip = new MTXZip(); + 174 is = mtxzip.iUnZip(is); + 175 revisionDescriptor.setContentLength(mtxzip.getLength()); + 176 } + 385 long contentLength = 0; + 386 if (bcompress) { + 387 getLogger().log("Compressing the data",LOG_CHANNEL,Logger.INFO); + 388 MTXZip mtxzip = new MTXZip(); + 389 is = mtxzip.iZip(is); + 390 contentLength = mtxzip.getLength(); + 391 } else { + 392 contentLength = revisionDescriptor.getContentLength(); + 393 } This is controlled from the domain.xml parameter for J2EEContentStore <contentstore classname="slidestore.j2ee.J2EEContentStore2"> <parameter name="datasource">jdbc/mtx_hologram</parameter> <parameter name="compress">true</parameter> </contentstore> If we all find that this is a nice feature to have, I will do some refactoring. See the attachment for the sources Ashok -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
