Fog Creek Software
Discussion Board




I'm wrong EJBs are not allowed to access files

In an earlier thread I had a discussion with a dickhead about whether not using local files with EJBs was a restriction or a recommendation.  Upon deeper reading of the EJB spec, I see I was wrong.  Although the J2EE spec says the container should grant read write file permissions, the EJB spec says it should not.  Even though JBoss seems to allow the Berkeley DB JE classes to access local files, this doesn't mean that it meets the spec.

name withheld out of cowardice
Friday, July 23, 2004

Threading is handled by the EJB container. Therefore the EJB can not
know or make any attempt to know about threading. By accessing files
you are force the EJB to consider and manage the possible co-current
access to the file, taking that control away from the container.

ITECS
Friday, July 23, 2004

J2EE != EJB.  Servlets are part of J2EE, and they are allowed to do things that EJB's shouldn't or can't.

NoName
Friday, July 23, 2004

No name, you are quite right.

ITECS- I'm not sure that is the reason.  I think it's more that they want the Container to have flexibility when clustering.  They think it's not appropriate to use the local file system. 

Anyway the file access is being done by berkeley DB Java edition which handles the concurrent file access issue, I think, by using the nio package.

Since I am abusing EJBs just to avoid doing some of the work of RMI, it isn't so much a problem for me.

name withheld out of cowardice
Friday, July 23, 2004


The point is conceded - I never though of clustering .However I believe
it might just be another aspect of the core concept of EJBs which is
that they are managed by an third party. Anything that allows the EJB
to break out of their containers is bad. One aspect on treading is
that the tread may be running on another machine
(clustering). Although it possible to make the file appear on other
machine it takes control away from the container -all containers are no longer equal. Thus the container
does not have freedom to tread your EJB as container/application manager
sees fix (by for example running it else where).

ITECS
Friday, July 23, 2004

Use mbeans

Berlin Brown
Saturday, July 24, 2004

UNIX uses file descriptors for a number of types of resources - not just files. And different resources behave in different ways ... some block on io, some don't.

In Win32 it's even worse. Any kernel resource can be handle - which is either an int or a void*.  And again each resource type has its own specifics on io.

I guess the container can't guess what's behind a particular file descriptor or handle and therefore cannot predict if the next call is blocking or not.

But I don't see any problem working with files if there is no concurent access to the file and the io is non-blocking.

More: one may ues JavaSpaces for resolving concurency on external resources - even in a clustered environment.

For non-blocking io, one can try and use nio, but that may be a challenge - maybe easier with message beans.

Dino
Sunday, July 25, 2004

Berlin-

mBeans?  How so?

Dino- I am using Berkeley DB JE which uses nio for file access.

name withheld out of cowardice
Monday, July 26, 2004

*  Recent Topics

*  Fog Creek Home