¿Cómo acceder al sistema de archivos desde un EJB 3?

Question

Me gustaría saber cómo puedo acceder al sistema de archivos desde un bean EJB 3?

He buscado en Internet sobre el tema y no he encontrado una buena respuesta.

Algunos sugieren utilizar java.io/java.nio aunque la especificación prohíbe este uso. La mayoría de los servidores de aplicaciones parecen permitir el acceso a esta API de todos modos.

Otra idea sería utilizar un conector JCA para acceder al sistema de archivos o a un directorio LDAP.

Lo que quiero hacer para evitar el uso de BLOB en la base de datos cuando un archivo simple sería una solución mucho mejor en términos de rendimiento y recursos utilizados.

¿Cómo resolvería este problema?

Answer 1

La razón por la que son No permitido el acceso de sistema de archivos en EJB es que usted no tiene control sobre cómo su aplicación se ejecuta dentro de un (Java EE) de contenedores. Por ejemplo, su aplicación puede ejecutarse a través de un clúster de servidores, en cuyo caso es poco probable que se guarde algún objeto en un directorio en un servidor. (Por supuesto, puede tener un sistema de archivos de red, por lo que es posible que la restricción no se aplique).

Una opción puede ser la de uso la JNDI aplicación que viene con su de contenedores. Probablemente, usted será capaz de guardar un byte[] gama prima en algún lugar JNDI, por lo que siempre se puede salvar por la forma serializada del objeto:

ByteArrayOutputStream baos= new ByteArrayOutputStream(); 
ObjectOutputStream oos = new ObjectOutputStream(baos); 
oos.writeObject(myObj); 

//Now save into JNDI 
new InitialContext().bind("path/to/myobject", baos.toByteArray()); 

Esto se puede consultar más adelante y se vuelve a convertir en el objeto:

byte[] bs = (byte[]) new InitialContext().lookup("path/to/myobject"); 
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bs)); 
MyObj myObj = (MyObj) ois.readObject(); 

como alternativa puede usar el java.beansXML persistente (es decir XMLDecoder, XMLEncoder) para codificar la instancia como una cadena XML que un ahorrar en JNDI.

Answer 2

Si sabe que nunca agrupará su aplicación (o que podrá mapear en red la unidad), simplemente use java.io. *.

Asegúrese de introducir una configuración adecuada con respecto a la ubicación raíz del almacenamiento de sus archivos.

Answer 3

Encapsule su acceso a los datos del archivo. Entonces podría usar cualquiera de los métodos descritos anteriormente. Incluso usa una base de datos. Mida el rendimiento de su sistema. Si cumple con los requisitos, está listo. Si no, su acceso a archivos está localizado en un lugar y puede sustituir una solución diferente. Mismo beneficio si el software tiene que ser portado a otro contenedor y/o debe ser mantenido por otra persona.

Answer 4

El acceso simple a archivos no es de naturaleza transaccional. A menos que genere soporte para operaciones transaccionales (no tengo ni idea de cómo es el trabajo de un administrador de recursos), tendrá que preocuparse por la semántica transaccional de la operación que está realizando. Si construye soporte de transacciones, hay muy poco que haya ganado en rendimiento (parte de la pérdida de rendimiento en las bases de datos se debe a toda la contabilidad realizada por el administrador de recursos). Y no olvides el primo cercano de la gestión de transacciones: concurrencia.A menos que empiece a escribir en un nuevo archivo para cada solicitud, los problemas de simultaneidad le morderán más o menos.

Encontrará mucha más información en el Sun Blueprint's FAQ on EJB restrictions.

A menos que tenga una buena justificación técnica, no debe intentar acceder al sistema de archivos desde los EJB. Un muy buen ejemplo sería un marco de registro (no de auditoría): hay relativamente menos daño al acceder al sistema de archivos para escribir archivos de registro, dado que el registro no tiene que ser una operación de transacción, es decir, no es necesario revertir las escrituras a un archivo. archivo de registro; no es aceptable escribir parcialmente.