<generalizing ... generalizing/> write a jca adpter for cvs and use this in a cvs appropriate manner ...
bax > > Write a JCA adaptor for a file based persistent store. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: Luttrell, Peter > To: '[EMAIL PROTECTED]' > Sent: Friday, January 03, 2003 11:37 AM > Subject: RE: [JBoss-user] Store large pdfs with JBoss > > > Actually i'm considering writing a little jmx service that manages the > filesystem store. my ejbs would store the key that the jmx service requires. > the service would then enforce/handle all such rules. > > I just read this however, which articulates some of the concerns with any > filesystem approach: > > From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: > > Why can't EJBs read and write files and directories in the filesystem? And > why can't they access file descriptors? > Enterprise beans aren't allowed to access files primarily because files are > not transactional resources. Allowing EJBs to access files or directories in > the filesystem, or to use file descriptors, would compromise component > distributability, and would be a security hazard. > > > Another reason is deployability. The EJB container can choose to place an > enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a > filesystem are not part of a deployment, and are therefore outside of the EJB > container's control. File systems, directories, files, and especially file > descriptors tend to be machine-local resources. If an enterprise bean running > in a JVM on a particular machine is using or holding an open file descriptor > to a file in the filesystem, that enterprise bean cannot easily be moved from > one JVM or machine to another, without losing its reference to the file. > > Furthermore, giving EJBs access to the filesystem is a security hazard, > since the enterprise bean could potentially read and broadcast the contents of > sensitive files, or even upload and overwrite the JVM runtime binary for > malicious purposes. > > Files are not an appropriate mechanism for storing business data for use by > components, because they tend to be unstructured, are not under the control of > the server environment, and typically don't provide distributed transactional > access or fine-grained locking. Business data is better managed using a > persistence interface such as JDBC, whose implementations usually provide > these benefits. Read-only data can, however, be stored in files in a > deployment JAR, and accessed with the getResource() or getResourceAsStream() > methods of java.lang.Class. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
