the prohibition of accessing a filesystem in an EJB is due to a number of
reasons, some of them being:
1. Usually it doesn't have a resource manager. Thus, operations on a
filesystem aren't transactional
2. Its capabilities(locking, sym-links) are OS dependant and usually not
quite Enterprise class.
3. It is usually local to the host where your app is executing, thus it
doesn't scale well. This partially untrue if you use, for instance, a RAID,
a distributed file system or some replication services; in fact, I have
built a replication service because of my need to manage files as RDBMS
aren't up to the job. However, most replication services only expose 1 & 2
more.
I can't think of anything else right now.
Despite that:
1. You can build a JDBC driver to encapsulate any filesystem, and build
resource managing capabilities on top of it. It's not an easy task, but it
is definetly feasible.
2. You can build independant replication services(I have done it) or
cooperative(with your JDBC driver) replication services. Or you can use NFS
or some RAID config to obtain a single front to your filesystems.
Or you can (if reuse isn't your concern and your app server is pure java and
you won't use more than one host) forget about all this and just go ahead
and do the deed.
I hope I provided a few options for y'all.
My 2c,
JP
> -----Original Message-----
> From: Steve Gardell [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 02, 2001 9:24 AM
> To: [EMAIL PROTECTED]
> Subject: File access, etc.
>
>
> We have an application that deals with a large
> quantity of multi-media data associated with a
> relational database. The multi-media files are stored
> directly on the file system. Conceptually they are
> columns in a database schema; however the reality
> is that relational databases are not really "up the task"
> of managing this data, so the relational database
> contains pathnames.
>
> We would like to manage these associated files via
> EJB. Basically this means creating, deleting, and
> returning pathnames. The EJB server would (at
> least typically) never be concerned with the contents
> of the files.
>
> We understand that the spec prohibits this but are
> at a loss to understand why. They are really just an
> element of our persistent store... We are hesitant to
> just cheat since we understand that access to file
> system might be "yanked" at any time.
>
> Along a similar vein, we can imagine storing persistent
> data in a variety of other places such as a Radius
> server, an IMAP server, an LDAP directory, etc. I
> imagine that there is something buried in the spec
> about using EJB's in such an integration role, but I
> can't find it.
>
> Any elucidating comments would be most welcome.
>
> Steven Gardell
> Principal Engineer, Iperia Inc.
> 781-993-3544
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
> ______________________________________________________________
> ______________
> For your protection, this e-mail message has been scanned for Viruses.
> Visit us at http://www.neoris.com/
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
