Sorry for the late reply everyone...I thought I was resubscribed (my @Home 
account was discontinued, and I kept procrastinating about updating my email 
addresses)...as it turned out, I missed the request for confirmation I had to 
reply to :(

Peter Levart wrote the following excerpt on Feb 13, 2002:

> There is a java.sql.Blob type that allows you to read/write binary data 
> from/to a BLOB field via InputStream/OutputStream without buffering the
> whole 
> chunk and to read/write parts of the BLOB field.

Yes, exactly the reason I want to use streams.

> Daniel probably wants to solve the problem of transporting a big chunk of 
> data from the client to the server and store this into a BLOB field in the 
> database.

Yes, because allocating memory for 20MB's of data would be processing 
prohibitive.

> What I would probably do in this case is something like that:

> 1. Open a transaction on the client side
> 2. Organize big data into byte[] packets of some length and send them to
> the 
> server via multiple calls to EJB. On the server side write each packet into 
> the appropriate offset of the BLOB field via java.sql.Blob type.
> 3. Commit transaction on the client side.

Aha!   Thanks, very much.  I didn't know you could update the LOBs via 
offsets.  Can you also do this for CLOBs and NCLOBs?

> Peter

Guy Rouillier wrote the following excerpt on Feb 12, 2002:

> Are you attempting to put a 20 MB file into a BLOB column in a database

Yes.

> table?  If so, I'd suggest you consider just leaving the file in the file
> system and putting a reference to it in a small character column.  What
> benefit are you deriving from putting a file into the database?

I'm not.  The specification requires it.

Dain Sundstrom wrote the following excerpt on Feb 12, 2002:

> Two things come to mind here.  First, values passed over local 
> interfaces don't have to be serializable. Second, EJBs are forbidden 

Nothing is passing over a local interface here.  JBoss is on one machine; 
Tomcat is on another.

> from performing IO, because IO can block forever (you can cheat of 

If this is the case, why does it allow me to perform LOB input/output within 
the context of a database statement?  I'm not doing any kind of a special 
hack to do it, but I'm certainly not using CMP, either.  I have to use 
Oracle's BLOB and CLOB datatypes.

> course).  How are you planning on getting this into the database?  You 
> can't create a CMP field of type Stream.

I'm not using CMP.  I'm accessing the datasource directly.

Paul Cody wrote the following excerpt on Feb 12, 2002:

> The notion of a serializable stream is not trivial.  At first glance, it
> suggests that your design may need reconsideration.  Can you expand on your
> overall requirements and the properties you expect from a serializable
> stream?

The project specification states that the information be stored in the 
database, not as a local file; this is supposedly to ensure that the data is 
not easily modifiable (I'm guessing here).  The servlet engine may or may not 
be on the same machine as the ejb engine.  The servlet engine will more than 
likely rest inside of a DMZ, and the ejb engine (as well as the database) 
will reside on an internal LAN or intranet, inside of a second firewall.  The 
operating system employed may be Solaris, Windows, HP/UX, or Linux (depends 
on user's requirements).  A user may choose to upload a file (as large as 20 
or 30 megabytes) to the servlet engine.  Another user may choose to download 
one of these uploaded files.  On the backend this is also done for new mail, 
using Javamail (I might decide to use something else...Javamail is turning 
out to be painfully slow...especially using the Sun JVM.)

The properties I expect to be able to receive from serialization is that the 
the port to the database remain secured from the DMZ; i.e. no access to the 
database from the DMZ.

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to