> > You state, very clearly, the reason for these restrictions when > > you say "I don't > > want or need the overhead of transactions". It is the very lack > > of transactional > > integrity that makes file IO "unacceptable". The fact that you > > cheat and make it > > work does not change this fact. > > > So, basically it boils down to this. Any (enterprise) application that has > the need for writing to flat-files (brazilian banks just love flat-files) > can not be an EJB application or need some separate appliaction to do this > work for me. I guess I�m not the only one that, every now and then, needs to > read or write some info to or from a disc.
I agree with you. There are times when file IO is mandated. And at those times, your design will need to reflect your level of commitment to the spec. There are systems that may stray from the spec, because they know their platform will never change for instance. However, there are other systems that will require absolute compliance with the specification. I believe that several people on this list have proposed solutions for file IO that comply with the specification. Those wishing to comply with the specification should use one of them. Those with more "freedom" would still be wise to wrap all of their file IO with an API so that it can most easily be adjusted to work in future environments. tim. ==========================================================================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".
