Как получить доступ к файловой системе из EJB 3?

Причина, по которой вам запрещен доступ к файловой системе в EJB, заключается в том, что вы не можете контролировать, как ваше приложение работает в контейнере (Java EE). Например, ваше приложение может выполняться на кластере серверов, и в этом случае сохранение какого-либо объекта в каталоге на одном сервере, скорее всего, будет бесполезным. (Конечно, у вас может быть сетевая файловая система, поэтому ограничение может не применяться).

Одним из вариантов может быть использование реализации JNDI, которая поставляется с вашим Контейнером. Скорее всего, вы сможете сохранить необработанный массив byte[] в каком-то месте JNDI, чтобы вы всегда могли сохранить сериализованную форму объекта:

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

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

Это можно найти позже и повторно преобразовать в ваш объект:

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

В качестве альтернативы вы можете использовать java.beans постоянный XML (т. е. XMLDecoder, XMLEncoder) для кодирования экземпляра в виде строки XML и сохранения его в JNDI.

Если вы знаете, что никогда не будете кластеризовать свое приложение (или что вы сможете подключить диск к сети), просто используйте java.io.*.

Обязательно введите правильную конфигурацию в отношении корневого расположения вашего хранилища файлов.

Инкапсулируйте свой доступ к данным файла. Затем вы можете использовать любой из методов, описанных выше. Даже использовать базу данных. Измерьте производительность вашей системы. Если он соответствует требованиям, то все готово. Если нет, доступ к вашему файлу локализован в одном месте, и вы можете заменить его другим решением. То же преимущество, если программное обеспечение должно быть перенесено в другой контейнер и/или должно поддерживаться кем-то другим.

Обычный доступ к файлам не является транзакционным по своей природе. Если вы не встроите поддержку транзакционных операций (я понятия не имею, как это сделать — это работа менеджера ресурсов), вам придется беспокоиться о транзакционной семантике выполняемой вами операции. Если вы встроите поддержку транзакций, вы получите очень мало производительности (некоторая потеря производительности в базах данных связана со всей бухгалтерией, выполняемой менеджером ресурсов). И не забывайте о близком родственнике управления транзакциями — параллелизме. Если вы не начнете писать в новый файл для каждого запроса, проблемы параллелизма будут более или менее кусать вас.

Дополнительную информацию можно найти в часто задаваемых вопросах Sun Blueprint об ограничениях EJB.

Если вы не находитесь в чистоте с хорошим техническим обоснованием, вам не следует пытаться получить доступ к файловой системе из EJB. Очень хорошим примером может быть фреймворк ведения журнала (а не аудита) — доступ к файловой системе для записи файлов журнала наносит относительно меньший вред, учитывая, что ведение журнала не обязательно должно быть операцией транзакции, т. е. вам не нужно откатывать записи в журнальный файл; не то, чтобы было приемлемо иметь частичную запись.