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

Я хотел бы знать, как я могу получить доступ к файловой системе из EJB 3 bean?

Я искал Интернет по этому вопросу и не нашел хорошего ответа.

Некоторые предлагают использовать java.io/java.nio, хотя спецификация запрещает это использование. Похоже, что большинство серверов приложений разрешают доступ к этому API.

Еще одна идея - использовать JCA-коннектор для доступа к файловой системе или каталогу LDAP.

Что я хочу сделать, чтобы избежать использования BLOB в базе данных, когда простой файл будет гораздо лучшим решением с точки зрения производительности и используемых ресурсов.

Как бы вы решили эту проблему?

Ответы

Ответ 1

Причина, по которой вы отказались от доступа к файловой системе в 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();

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

В разделе "Часто задаваемые вопросы по Blue Blueprint" вы найдете гораздо больше информации об ограничениях EJB.

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