Skip to content

Other tips

Jump to bottom
Mark Rotteveel edited this page Jul 19, 2015 · 1 revision

Outdated information

Limit of connections

Q: Is there a maximum number of simultaneous connections in Firebird 1.5? Is there a practical limit or a number that would affect the performance? Is there any limitation related to Jaybird?

A:

Niki Ivanchev: I can remember an old thread in firebird-users list and some one stated that firebird have hardcoded limit of 1024 connections.

Helen Borrie: That is the theoretical limit for TCP/IP. The theoretical limit is lower for Windows named pipes (”NetBEUI?”) – the server is likely to hang at more than 930 concurrent connections. As a practical guideline, work on a base maximum of about 150 concurrent Superserver clients for a normal interactive application on a server of low-to-medium specification, with low-to-moderate contention, before performance might make you consider upgrading (and this is without taking the needs of the JVM into account). For Classic, the numbers may be lower because each client consumes more resources.

About the one thing you can be certain about is that there is no certainty, even if you think you’ve got it right by adding up numbers. Every user connection drains resources that the database server could otherwise use. Database servers love memory. There will always be some critical point at which the number of connected users is using more resources than the database engine can spare. In other words, there are theoretical limits and there are practical limits. Only proper reality testing can get you the right answer for your site.

Roman Rokytskyy:

Is there any limitation related to Jaybird?

No. But you have limitations of the JVM itself, for example maximum heap size.

Metadata changes are not visible

Q: I have a database accessed by a web application and a connection pool. When I do a metadata changes while the web application is running, it does not notice the changes. Restarting the web application solves the issue.

A: Most likely this is caused by Firebird metadata cache. Usually metadata are cached on connect and under some conditions the metadata cache might not be invalidated. When the web application is restarted, connections are re-opened and the changes become visible. Restarting the connection pool would have the same effect.

It must be also clear that it is a bad practice to modify the metadata in the active database.

Hibernate

Provided for historic purposes only

JayBird 2.0 was tested with the Hibernate 3.0 test suite. From the first sight execution can be considered as complete failure - success rate was very low. However following issues were discovered:

  • many tests use NUMERIC(38, 19) which is not supported by Firebird, maximum precision by Firebird is 19. No workaround except fixing the mapping.
  • most tests define string ID properties without specifying the length, which is converted into CHAR(255) during table creation. This causes “key size to big for ...” error for Firebird 1.5.x servers, works ok for Firebird 2.0, where the limit on the key size is extended to 1/4th of page size.
  • few tests use column names that are reserved words in Firebird.
  • when running against Firebird 1.5, an “gds internal consistency check. index parent page not found(175)” happens during changes in foreign key relationships. Everything is ok when tests are executed against Firebird 2.0.

After the changes in the .hbm.xml files and running tests against Firebird 2.0, the success rate is comparable when executing against HSQLDB (interesting enough, there is no 100% success against default configuration).

Debug

Provided for historic purposes only

P6Spy (not updated since 2003) is a proxy that intercepts JDBC calls and logs them into a specified file. Later the log can be analyzed with the separate GUI, like IronTrack SQL (was www.irongrid.com seems to be no longer available) tool that aggregates the data in the log and presents the JDBC activity on a diagrams.

In order to make P6Spy run with Jaybird you have to change your application to load the com.p6spy.engine.spy.P6SpyDriver JDBC driver instead of Jaybird. Additionally you have to tell the P6Spy to use Jaybird for the real work. This is done by modifying the spy.properties file and specifying:

realdriver = org.firebirdsql.jdbc.FBDriver

For more information please check the P6Spy documentation (broken link was www.p6spy.com/documentation/index.htm).

Sun Application Server

Provided for historic purposes only, deprecated in 2.2, to be removed in 3.0

Sun Application Server 8.1 (Platform Edition as well as Enterprise Edition) have introduced new algorithm to data source configuration and it does not work with regular pool classes shipped with Jaybird:

  • property for database path in Jaybird is called database, but Sun App Server supports only databaseName. Seems to be a bug; no workaround for regular pool classes exists. It is required to use new Sun App Server specific classes:
  • org.firebirdsql.pool.sun.AppServerDataSource as an implementation of the javax.sql.DataSource interface;
  • org.firebirdsql.pool.sun.AppServerConnectionPoolDataSource as an implementation of the javax.sql.ConnectionPoolDataSource interface;
  • org.firebirdsql.pool.sun.XADataSource as an implementation of the javax.sql.XADataSource interface;
  • it traverses through all properties, fetches default values, merges them with the specified ones and sets all properties back. This algorithm does not work with properties that are interconnected, for example, encoding and charSet. A simple workaround for the case if you specify one of them, is to set another property to the correct value too.

Interconnected properties:

  • encoding and charSet - see Character encodings for the mapping
  • loginTimeout and blockingTimeout - blocking timeout is a login timeout in milliseconds
Clone this wiki locally