2009-08-31 7 views
23

Chciałbym wiedzieć, w jaki sposób mogę uzyskać dostęp do systemu plików z komponentu EJB 3?Jak uzyskać dostęp do systemu plików z EJB 3?

Przeszukałem Internet na ten temat i nie znalazłem dobrej odpowiedzi.

Niektórzy sugerują używanie java.io/java.nio, nawet jeśli specyfikacja zabrania takiego używania. Większość serwerów aplikacji i tak wydaje się zezwalać na dostęp do tego interfejsu API.

Innym pomysłem byłoby użycie złącza JCA, aby uzyskać dostęp do systemu plików lub katalogu LDAP.

Co chcę zrobić, aby uniknąć użycia obiektu BLOB w bazie danych, gdy prosty plik byłby znacznie lepszym rozwiązaniem pod względem wydajności i używanych zasobów.

Jak rozwiązać ten problem?

+1

Nie musisz mieć obiektu BLOB w bazie danych. SQL Server 2008 obsługuje magazyn plików, który zasadniczo zrzuca plik do folderu na serwerze DB, ale udostępnia go za pośrednictwem bazy danych. http://blogs.msdn.com/rdoherty/archive/2007/10/12/getting-traction-with-sql-server-2008-filestream.aspx – pjp

Odpowiedz

9

Dlatego, że jesteś zabronione z dostępem do systemu plików w EJB jest to, że nie masz kontroli nad tym, jak aplikacja działa w (Java EE) Container. Na przykład aplikacja może być uruchamiana w klastrze serwerów, w którym to przypadku zapisanie jakiegoś obiektu do katalogu na jednym serwerze może być mało przydatne. (Oczywiście możesz mieć system plików sieciowych, więc ograniczenie może nie mieć zastosowania).

Jedną z opcji może być użytkuJNDI realizacji, która pochodzi z Container. prawdopodobnie będziesz w stanie zaoszczędzić surowiec byte[] tablicę w pewnym miejscu JNDI, więc zawsze można zaoszczędzić w dół zserializowaną formę obiektu:

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

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

ten można zapoznać się później i ponownie przekształcony swojej obiektu:

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

Alternatywnie można użyć java.beansuporczywy XML (tj XMLDecoder, XMLEncoder) do kodowania instancji jako ciąg znaków XML zapisać, że w JNDI.

+0

Czy to jest zalecany sposób zapisywania plików z EJB? Czy plik będzie dostępny dla każdego węzła w klastrze (myślę, że JNDI rzeczywiście jest w klastrze, więc prawdopodobnie tak)? Ostatnie czytanie do (lub pisanie z) JNDI jest transakcyjne? –

+0

"jesteś niedozwolony" - nie jesteś już dłużej zabroniony, aby uzyskać dostęp do systemu plików i NIGDY nie zamierzano, aby miało to tylko zastosowanie do specyfikacji EJB. Ktokolwiek to napisał w tamtym czasie, był złudny, że EJB będzie podstawą całej Java EE, a co za tym idzie, prawie równa się Java EE. –

7

Jeśli wiesz, że nigdy nie zgrupujesz aplikacji (lub że będziesz w stanie mapować dysk), po prostu użyj java.io. *.

Pamiętaj, aby wprowadzić poprawną konfigurację dotyczącą lokalizacji głównej przechowywania plików.

+0

+1 Ta odpowiedź jest tylko * zdrowym rozsądkiem *. Jeśli plik jest wypełniony przez inny program (który nie jest zgodny z EJB), nie ma szybszego i * wyraźnego * sposobu na zrobienie tego. – ATorras

+2

Pisząc aplikację, która nie jest zgodna ze specyfikacją Java EE, nie można mieć pewności, że jest ona przenośna i możliwa do utrzymania. Na przykład w ciągu 12 miesięcy możesz zostawić ten projekt z dużą niespodzianką dla biednej osoby, której zadaniem jest grupowanie aplikacji. Lub przeniesienie go do innego kontenera. –

+7

* "Jeśli wiesz, że nigdy nie zgrupujesz swojej aplikacji" * - jeśli okaże się, że możesz spojrzeć w przyszłość, możesz pomyśleć, że istnieje bardziej lukratywna kariera, która kusi w branży gier hazardowych. –

5

Kapsuł swój dostęp do danych pliku. Następnie możesz użyć dowolnej z metod opisanych powyżej. Nawet korzystaj z bazy danych. Zmierz wydajność swojego systemu. Jeśli spełnia wymagania, to jesteś gotowy. Jeśli nie, twój dostęp do pliku jest zlokalizowany w jednym miejscu i możesz zastąpić inne rozwiązanie. Ta sama korzyść, jeśli oprogramowanie musi zostać przeniesione do innego kontenera i/lub musi być obsługiwane przez kogoś innego.

+0

+1 do enkapsulacji – flybywire

1

Zwykły dostęp do plików nie ma charakteru transakcyjnego. O ile nie wbudujesz obsługi operacji transakcyjnych (nie mam pojęcia jak - to jest zadanie menedżera zasobów), będziesz musiał się martwić o transakcyjną semantykę operacji, którą wykonujesz. Jeśli wbudujesz obsługę transakcji, niewiele osiągniesz w wydajności (niektóre straty w wydajności w bazach danych wynikają z całej księgowości wykonanej przez menedżera zasobów). I nie zapomnij o bliskim kuzynie zarządzania transakcjami - współbieżność.Jeśli nie zaczniesz pisać do nowego pliku dla każdego żądania, problemy z współbieżnością będą cię mniej lub bardziej ukąsić.

Znajdziesz więcej informacji w Sun Blueprint's FAQ on EJB restrictions.

Jeśli nie masz jasnego uzasadnienia technicznego, nie powinieneś próbować uzyskać dostępu do systemu plików z EJB. Bardzo dobrym przykładem byłaby struktura logowania (nie audytująca) - istnieje stosunkowo mniejsza szkodliwość w uzyskiwaniu dostępu do systemu plików w celu zapisywania plików dziennika, ponieważ rejestrowanie nie musi być operacją transakcji, tzn. Nie trzeba zapisywać zapisu do plik dziennika; nie jest to dopuszczalne, aby mieć częściowe zapisy.

+0

Buforowanie plików lokalnie za pomocą Singleton/timer jest kolejnym przykładem operacji, która jest prawie zawsze bezpieczna. –

+1

"O ile [...] nie powinieneś próbować uzyskać dostępu do systemu plików z EJB" - nie ma absolutnie żadnego konkretnego powodu, dla którego miałoby to dotyczyć jedynie EJB. Należy zachować ostrożność podczas wykonywania IO z * każdego rodzaju fasoli *, a nie tylko z fasoli, które są fasolami EJB. –