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

Question

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

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

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

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

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

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

Answer 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();

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

Answer 2

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

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

Answer 3

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

Answer 4

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

В разделе часто задаваемых вопросов Sun Blueprint об ограничениях EJB вы найдете .

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