Roman,

Thanks for your comments, and thanks for a great package. I have used Jaybird for many years and find it very dependable and quick. This is the first time I have noticed a difference between Jaybird and ISQL.

The connection through ISQL is on the same host, 'connect localhost:CBASE' where CBASE is in the aliases.conf file. The connection string through JDBC is, 'jdbc:firebirdsql:localhost/3050:CBASE' with no connection parameters.

Regarding the buffers -- as this is a read-intensive, not update-intensive application, it sounds like the 2048 buffers should not cause a problem, right?

- Steve

--- In Firebird-Java@yahoogroups.com, Roman Rokytskyy <roman@...> wrote:
>
> > As reported by 'top', the VIRT memory of an fb_inet_server process created through jdbc is 32meg while isql's fb_inet_server process size is larger at 49meg. I am hoping to track down why the size of an fb_inet_server process created through Jaybird/JDBC would be so different than the size of the an fb_inet_server process created through ISQL. The size of the each process does not change significantly while queries are being performed. How can I make the memory footprint of the JDBC connections more like the ISQL connection?
>
> I wonder if iSQL and Java process use different connection parameters.
> The default DPB should be the same, and it should consume then the same
> amount of memory.
>
> But I have another question - how do you connect to your database with
> iSQL? Is on the same host? What is your CONNECT string looks like?
>
> > p.s. While I am using the classic server architecture, there are only 8 connections in a connection pool, so my understanding was that 2048 buffers was not too much -- 8 meg/connection * 8 connections = 64meg devoted to buffers. Is there some other reason besides memory to keep the number of buffers low in this set-up?
>
> When you update record, a page gets invalidated among all Classic
> instances and will be reloaded. So with update-intensive application you
> will just waste your memory. In a SuperServer you have a shared cache,
> so an update will not cause page reload from the disk.
>
> Roman
>