9 Replies Latest reply on Mar 10, 2002 8:30 PM by ~adrian

    Filesystem access from EJB


      I am working on an application that manages web hosting, kindda like geocities. The application has two kinds of users:
      - Authors, who upload content, and
      - Audience, who access this content by web.
      Naturally, there is a lot of traffic from the audience, but not much by the authors. What I would like to do then, is to have a static apache server do the hosting directly from the filesystem, and a J2EE application for the authors.
      The problem is, there is currently no standard method of accessing the filesystem from the EJB; access to filesystem using java.io is in fact not allowed by the specifications. Such access could indeed be harmful because it is not transactional, and I am not aware of any transactional interface to the filesystem that is currently available (maybe JDO will allow that, but that could take years).

      On the other hand, putting megabytes of media files on database BLOBs can be expensive on the database-side, and slow down the access to these files.

      Anyone knows of any standard solutions to this dilemma?
      Anyone has any new ideas of how it can be solved?

        • 1. Re: Filesystem access from EJB

          Oracle iFS lets you store data in the database (so presumeably it is transactional) but provides a view of the database data that looks like an ordinary file residing on an ordinary volume. I'm not sure this would provide the performance you are looking for but one could try it out to see how well it works.

          • 2. Re: Filesystem access from EJB

            I believe the most appropriate solution for this is using an MBean to access the filesystem. This would create a clean separation between the dynamic content management and static web page server.

            However, I really can't think of a nice way of doing the multiprocess access to the file-system. (Writing from MBean, reading from web server, such as Apache.)

            I would seriously consider using a db instead. If you chose a db based on its ability to retrieve large blobs in a short time, it might work out. If I read you correctly, you don't really need things like referential integrity.

            And also, do you really need transactions? If atomic updates is all you need, you lose the transaction overhead.

            Åsmund Hjulstad

            • 3. Re: Filesystem access from EJB

              Meanwhile I have two interesting leads.

              One is an article from ONJava.com, which forms an initiative for transactional filesystem access. If I choose to implement an MBean, an advanced implementation of this system can be used. It can be found on http://www.onjava.com/pub/a/onjava/2001/11/07/atomic.html .

              Another idea is to talk to the webserver by WebDAV, implementing an MBean that manipulates files and handles transaction on a remote web server. However, the WebDAV implementations I know use regular SQL underneath, so there is no real advantage in that; I do suppose other implementations might actually use a filesystem (such as with RCS or CVS). If anyone has any ideas on this, please post them!


              • 4. Re: Filesystem access from EJB

                Hi guys,

                I used JNDI with a file system implementation,
                File System Service Provider.


                It provides a cheap and easy solution, but I don't
                know if this is really scalable.

                Julien Viet

                • 5. Re: Filesystem access from EJB

                  How scalable does this need to be? Do you need transactions? Are JBoss/Jetty (or Tomcat) running on one machine together?

                  One simple solution we used at my last job was to create an UploadJspHelper.java class that a jsp page could use. According to our config file, it knew where to write the uploaded file. Of course the problem is if you have more than one server, you've either got to have a common file system through NFS or you've got to replicate the files to each machine.


                  • 6. Re: Filesystem access from EJB

                    Sounds like oscache is the tool that you need.

                    Allows you to have whatever dynamic content you need, but cache it on the file system when it is not updated.

                    There are jsp cache tags & servlet filters for caching other content (eg. Dynamically produced images).

                    Find it here:

                    A way in which you could use it, is draw all your content from the database, but cache it using oscache. When the author does an update, flush the key for that cache, and next time the content is requested, it will be retrieved from the database & recached.

                    Advantages of this are that you can access the same cache from many servers (assuming they are all networked to the fileserver), allowing load balancing.

                    Disadvantages are that you would have to use a jsp / servlet container to serve your content.


                    Scott Farquhar :: scott@atlassian.com

                    Atlassian :: http://www.atlassian.com
                    Supporting YOUR J2EE World

                    • 7. Re: Filesystem access from EJB

                      you can use entity beans , and change the persistent layer beneath it.
                      You can change the persistent engine to be file based.
                      you still have your transaction being care of by the container.

                      • 8. Re: Filesystem access from EJB

                        Why are you going to use EJB's? In your concrete case I find that EJB's would just be non-recommendable. Use them just to access the DB and that's all.

                        Authors are not going to submit things via more than one channel. Keep atomicity in actions and you don't need transactions. What more?

                        • 9. Re: Filesystem access from EJB

                          You could use a text JDBC driver. Is J2EE compliant (datasource). It will be the driver responsability to write to the local filesystem into a csv file for example.