Monday, January 13, 2003, 12:14:44 PM, you wrote: GB> Darren Hartford [mailto:[EMAIL PROTECTED]] wrote: >> Outside of JBoss, with Content Management Systems, the most >> common problem is how to handle large amounts of data, GB> That's what RDBMSs are designed to do well. There are plenty of GB> databases out there that contain terabytes of data in tables. >> The best approach to this is to have two keys in your >> database - one that is the unique identifier of the file you >> are looking for, the the second is the actual pointer to the >> file. This way, if you HSM and move files to CD/DVD, you're >> system still maintains integrity of the unique identifier for >> lookups, but the pointer can change as-needed.
GB> If your application crashes (or your network goes down, or whatever) GB> after writing the database row, but before writing the file, your GB> database will contain invalid data (a pointer to a nonexistent or GB> outdated file). If it crashes after writing the file, but before GB> writing the database row, you'll have lost a file (it will be there on GB> disk, but there will be no pointer to it in the database). Worse yet, GB> your application could crash while it's in the middle of writing a file, GB> in which case you're left with a corrupt file. The solution for this is write a JCA adaptor for a file based persistent store, as already pointed on this thread. With this the file store will support transactions too. -- Best regards, Danilo mailto:[EMAIL PROTECTED] ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
