How far is file access recommended in EJB ?


EJB design: How far is file access recommended in EJB ?

  1. How far is file access recommended in EJB ? (7 messages)


    I have a requirement where might have to store large size files. I am trying to see whats the best option under this circumstance. I am currently using

    EJB 2.0, CMP 2.0

    ** When you want to store big size files, sometimes you can and sometimes you cant, and when you store it the database performance goes slow. Alot of people have different views, some say store to file system and some say stick to databse. I was looking for views from experts out there about this matter.

    ** I read that EJB 1.1 spec restricts from writing into a file system from ejb's. Has anything changed in EJB 2.0 or EJB 2.1 with respect to this issue ? If yes, can someone point me to the section where it talks about this matter.

    ** I was also considering JDO's .... how far is it a choosable option against entity beans when it comes to storing huge data.

    So for such a situation, which of the following are better

    (1) BMP
    (2) JDBC to store blobs directly to database rather than using CMP Create and Finder methods.
    (3) Storing to underlying filesystem
    (4) Using JDO's


    Meka Toka
  2. Well it depends. If your application is going to run in a clustered environment then keep your hands away from it, except if you never want to read the file again, if otherwise you have to be sure that you are going to access the same machine again. (Except you have somesort of network mounted filesystem.)

    I´m not sure about the latest specs but I do not think it is "recommended".

    BLOB with BMP sounds for me the best way to go.
  3. As David explain, the restriction is mainly due to cluster problematic. You can also meet synchronization troubles in some rare cases.
    One way to cope with the spec limitation (and especialy with the cluster limitation) is to create your own rmi file service. It's very easy, but becareful to correctly implement concurrent file accesses.
    This service is deployed on one server and can be contacted by any ejbserver of the cluster.


    nicolas frank
  4. From the spec,

    "• An enterprise bean must not use the package to attempt to access files and directories in the file system.

    The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data."

    So how I always read this is that since the file system does not have the concept of transaction isolation, threading, rollback/commit etc and EJBs are meant to model business components and their workflows, then you should not use the file system to manipulate business data. This however does not stop you from having classes that write log files, store/retrieve images etc.

    On a personal side, it is amazing to me how people react to to this paragraph in the spec. For example there are projects I have worked on that have amazingly complex (slow) logging systems under the arguement that opening a log file will break the spec. In those cases I think people read the words of the spec but miss the intent.

    The same issue exists with people who create and run threads in the container. They will point to the fact that they are starting the thread in a Servlet/utility class an not an actual EJB. Once again missing the point entirely of why the container exists and the job it does.

  5. Hi guys,

    I happen to solve my problem by writing the files to the filesystem. I ahcieved this by creating an MBean and starting up as a service. Binded it, so that my beans can look it up and send the Blobs to it to be written to filesystem and wrote the resource URL into the database.

    Well for now it solved my problem, but as the users above pointed i might be facing problems if i have to implement Clustering. Well this method serves my purpose until we go to production, I am also investigating Object databases that may be able to do the work of storing BLOBS for me.

    My application also needs to be fast, although it doesnt need to be super fast.If anybody has any views on this issue i would appreciate it.


    Meka Toka
  6. "I happen to solve my problem by writing the files to the filesystem. I ahcieved this by creating an MBean and starting up as a service. Binded it, so that my beans can look it up and send the Blobs to it to be written to filesystem and wrote the resource URL into the database"

    Have you not missed the point of M(Management) beans? They are meant to allow you to manage you server in a defined way not to access the fie system.
  7. I am relatively new to the concept of MBeans. All i know of now is how to write a simple MBean, and how to deploy it.

    Got a JMX bok recently, need to read it. For now that seemed to be a temporary solution to me, as posted by someone in a java forum

    here is the original quote
    "The spec still has that same restriction, they always put them in chapter 25, "Runtime Environment". If you decide you want to sidestep the database and store the large files to the filesystem, I have done something like this before using a separate service (Could be JMX, CORBA, RMI, etc.). The service is bound to a name in JNDI so that an EJB can look up the service and invoke it's methods using a JNDI name. I know with Weblogic there were startup services available so that the service could be started and bound to JNDI with the container. "

    and the url to it is


    Please do let me know of what you think, appreciate it


    Meka Toka
  8. Oops missed the url

    here it is