Re: statement caching patch from Laszlo Hornyak for review
| От | Paul van den Bogaard |
|---|---|
| Тема | Re: statement caching patch from Laszlo Hornyak for review |
| Дата | |
| Msg-id | 670726BC-C614-41DA-B1F3-03DC49441690@sun.com обсуждение исходный текст |
| Ответ на | Re: statement caching patch from Laszlo Hornyak for review ("Laszlo Hornyak" <laszlo.hornyak@gmail.com>) |
| Ответы |
Re: statement caching patch from Laszlo Hornyak for review
|
| Список | pgsql-jdbc |
Hi, I am quite new in the PostgreSQL arena. However I know there are drivers that do implement SC (Oracle, mySQL, third party drivers for DB2). I believe the application servers have this build in out of pure necessity: when they needed it there simply were no drivers available that offered this. Therefore the motivation "most of them have it, so why should we offer it" sounds not too motivational to me. I believe that since a statement is part of a connection the proper place for a pool is within that connection (to me at least from an architectural/design point of view). I feel any self respecting driver should offer SC. Of course in a way that can also be used by applications that have no need for it. Either because they know each/ most statements are a one time thing or for other reasons. Of-course in a safe way, although I am not sure a wrapping object is the only way to ensure this. This however is an discussion of implementation. Why do I dare to make this bold statement? First there are many more applications out there that use a database but are not J2EE. Therefore these would not benefit from SC build into application servers. Second all the ISVs I have been working with (the majority in the finance, erp, crm, telco segments) use a (transactional)database. Some of them are using non prepared statements. Most of them are using or planning to use prepared statements. All these ISVs use Oracle and the Oracle JDBC driver (I only did meet one that also offered a home made Oracle driver). They all use the SC feature. Third these ISVs have so much work to do in their build,test,release cycle that they will not easily accept another database. Let alone a database that mandates the use of yet another element (the SC wrapper) to get a feature they do need. Fourth, the code they need to maintain is already so large that they do not want to implement a SC feature themselves. Hopefully these practical reasons are also taken into consideration in the discussion if SC needs to be(come) part of the core. Regards, Paul ------------------------------------------------------------------------ --------------------- Paul van den Bogaard Paul.vandenBogaard@sun.com CIE -- Collaboration and ISV Engineering, Opensource Engineering group Sun Microsystems, Inc phone: +31 334 515 918 Saturnus 1 extentsion: x (70)15918 3824 ME Amersfoort mobile: +31 651 913 354 The Netherlands fax: +31 334 515 001
В списке pgsql-jdbc по дате отправления: