Hello, see my answer below your questions. > -----Original Message----- > From: Sven Köhler [mailto:[EMAIL PROTECTED]] > Sent: Donnerstag, 16. Januar 2003 23:06 > To: [EMAIL PROTECTED] > Subject: [JDBC] various questions > > > Hi! > > I'm using Java 1.4.1 and i think this means that i'm using JDBC 3.0. > > 1. is the SAPDB-driver doing connection-pooling in any way? > is there any mechanism integrated into JDBC 3.0 that would > help me with > that? or do i have to implement my own connection-pooling?
The current available JDBC-driver (ftp://ftp.sap.com/pub/sapdb/bin/java/sapdbc.jar) supports the JDBC 3.0 Api including the JDBC optional package javax.sql.*. At the moment a JDBCRowSet (implements javax.sql.RowSet) is in a beta state and not contained in this driver. So, the driver provides all these interfaces needed by a connection-pool-manager which is usually part of a J2ee-server. The Factory class for creating a connections is com.sap.dbtech.jdbcext.DataSourceSapDBFactory. > 2. the cache-paramter seems very promising, how does this > cache behave? > which size does it reach? how does it the cache decide which > statement > should be kicked next if the cache is full? > can i somehow control if a statement is put into the cache? Prepared statements will be cached per connection in a hashtable. This probably improves the performance of your application by avoiding unnecessary parsing of equal sql statements. The default size of the cache is 1000 statement. You can change the cache size by setting the connect property "cachesize=<number oj max. cached statements>". A LRU-algorithm will displace old cache entries if the cache is full (for further details have a look into the sources). You can influence the cache behaviour using the connect property "cache=[all|s|i|u|d]". cache=all, all types of SQL statements will be cached cache=[s][i][u][d], depending on the letters you have set, different classes of statements will be cached s SELECT statements are cached i INSERT statements are cached u UPDATE statements are cached d DELETE statements are cached Example: If you define cache=siu, all SELECT-, INSERT-, and UPDATE statements are cached. The default is a disabled caching. The parameters are also explained at: http://www.sapdb.org/jdbcSapdbcEng.html#Connect_Properties > 3. the unicode-paramter irritates me. shouldn't this be used > by default > in combination with unicode-databases? > and happens if i use unicode=yes with a non-unicode database? > i guess "no" is default (default isn't mentioned there) You should set this connect property to yes (default is no) only if your sql statements really contains unicode data (for example your table-/columnname or username contains unicode character). Then all communication packets sended to the database kernel by the JDBC driver are encoded in UCS2 instead of ASCII. Because UCS2 packets needs much more space than ASCII packets this will decrease the performance and you should set this parameter only if you really need it. If your application handles unicode data only as parameter of the statements or in resultsets you don't need the unicode property. Regards, Marco ---------------------------------------------- Marco PASKAMP SAP DB, SAP Labs Berlin SAP DB is open source. Get it! www.sapdb.org _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
