Yeah, the IO might work, except that it violates the spec. Doesn't really
hurt orion, but makes your EJBs not very distributable, since they have to
be on the same machine where the files are stored. I wrote a simple RMI
server that sits on the file server and receives a byte[] from EJBs. Then
you can put the EJBs wherever, and not worry about being tied to the file
system.
No, there is nothing wrong with using a blob either, might be a big slower
too. And going with RMI, you could make things more optimized (like having
a key and then emulating streaming across the network). Then you could find
a middle group between network traffic and memory bandwidth on the VM.
Sending one byte at a time a million times is SLOW, but sending a
byte[1000000] will kill your server. Doing it with RMI will let you find
that middle ground, doing it with BLOBS will require you to load up the
entire file in to memory all at once.
-Pat
At 11:51 AM 7/23/2001 -0600, Nick Newman wrote:
>Two part answer ...
>
>1)
>
>Another possible option is to make up a unique file name, and write the
>file to that. Keep the name of the file (plus mime type, etc) in the
>EJB. The "getFile" and "setFile" methods would read/write to this
>file. You could use the ejbRemove method to delete the file. (And perhaps
>you will need other code to keep the files consistent with the DB).
>
>This is not so pretty in some ways (you have extra things to keep
>straight) but it avoids the need for anything special in the DB.
>
>Then again, perhaps this violates the strict specs about use of file IO in
>an EJB? In any case, this is what I have (successfully) used.
>
>2)
>
>I don't think there's any reason you couldn't use BLOBs. The specs don't
>include them, but the specs don't even assume you have a database, do they?
>
>Nick
>
>At 10:06 AM 7/23/01 -0700, you wrote:
>>Problem, persisting a downloaded file in a cmp ejb.
>>
>>Has anybody solved this problem? It seems like this is a problem not solved
>>by the specification.
>>
>>A plan of attack:
>>
>>1. web user uploads file through a form.
>>2. servlet processes file as an ArrayList of bytes with Nick Newman's
>>servlet (www.orionsupport.com/articles/downloads/UploadServlet.zip) with
>>some modifications.
>>3. file (now a List) is a member of a cmp bean with a list type Byte.
>>
>>If we use this method, each byte is stored in a separate table. Kindof ugly.
>>Talk about a large table!
>>
>>B plan of attack:
>>
>>1. web user uploads file through a form.
>>2. servlet processes file as a byte array with Nick Newman's servlet
>>(www.orionsupport.com/articles/downloads/UploadServlet.zip).
>>3. A class called FileBytes is created which implements Serializable, the
>>only member is the byte array.
>>4. A cmp ejb with members mimetype, name, datetime, and filebytes.
>>
>>Both of these methods require no hacking of the orion-ejb-jar.xml. We would
>>have to be satisfied with sql type long raw for most databases, however,
>>since the ejb spec doesn't include blobs. This means a limit of 2 GB...not
>>enough for a movie, but plenty large enough for anything else. Obviously we
>>should limit the size of the file, since all of the bytes have to be in
>>memory. Otherwise, we can break up the persitance into many 1 MB ejb's, each
>>with part of the file. This way, we don't have to have the file all in
>>memory at once.
>>
>>If anybody has done this, let me know. I would like to hear some comments,
>>also. I will keep you posted on my experiences.
>>
>>Regards,
>>
>>the elephantwalker
