> What is different in auto-commit mode?

Complete result set including blob content is cached in the memory.

> Memory is a problem here, since not all images are for the web site
> itself; some contain landscape images which have several megabyte...

If you want to load them into memory - use either byte[] or auto-commit
mode. If you want to pipe them directly - use InputStream.

> This should not be a problem either using a connection pool with a high
> maximum number of connections?

You have to check how your system behaves.

> I am not planing on synchronizing, because every thread has it's own
> Connection and since none of them writes to the database, no locking
> should occur. (Here my question about autocommit, which I think the pooled
> connections are by default...)

Firebird has no record locking anyway, but multiple connections will compete
for database anyway.

>> So you have to create tests anyway (my tests show me
>> something ~48 Mbit/s for reas and ~32 Mbit/s for writes on
>> Pentium M 1,6 MHz laptop, Windows XP, locally running FB 1.5 SS).
>
> Are you sure about MBit or did you mean MByte? 48 MBit read spead seems
> less than I expected, exspecially since the harddrives here on my dev
> system do about 60 mbyte / sec and the productive system is striped... I
> assume the FileImputStream will have way better troughput...

That's what one of the JUnit tests in JayBird tell me - 6 MByte/s = 48
Mbit/s. Write your own test and check it.

> Anyway, my concerns are not about throughput. My concers are about
> latency. I assume settings up a FileInputStream is way faster than
> getting an InputStream from a database query.

True.

> This is my biggest concern. I think the throuput (of several threads)
> will be limited by the nic card, but latency is always problem.

Your web server limits the number of threads in the system, not the nic
card. Feeding data from the database is always slower than file system
(remember, database itself is stored in the file system). When we developed
a site designed for really heavy load we have generated static image of it
on each change in the CMS and replicated it to multiple web servers that
were behind the load balancer, only the database-related stuff was
dynamically generated. Images were stored on the FS in all cases (we had no
dynamic image generation).

What you can think of is the temp cache on the file system. You application
would check first if image is on the file system, if not pump it from DB,
and save to the FS in parallel.

Roman