On Sat, Nov 10, 2001 at 03:00:27AM -0600, Bob Tanner wrote: > Quoting Florin Iucha (florin at iucha.net): > > On Fri, Nov 09, 2001 at 03:15:14PM -0800, Mike Bresnahan wrote: > > > Another thing to note is that some (all?) JDBC 2.0 compliant drivers support > > > connection pooling. This is generally a huge performance win. A lot of > > > time can otherwise be wasted opening and closing physical connections. > > > Without such support I end up coding my own connection pooling is most > > > cases, and thus JDBC 2.0 saves me the effort. > > > > Connection pooling is nice when you implement your own security layer. > > But when each connection uses different acounts, then it's almos useless. > > > > And implementing your own security the _RIGHT_(tm) way it's _HARD_. > > Nice comment. In all the java based applications I have written I have never run > into this issue. It kind of shocked me. > > Most of the apps I work on authentication is handled at application layer, not > the database layer. > > Is this uncommon to everyone else? > > More or less the DB is just persistent storage. Ask the DOD if they would like "system/manager" or "coolapp/oracle" embedded in the code somewhere (or in .properties, or .ini). It must be somewhere because you need code running at the privilege level of the user to get it, so it can connect to the database. Shopping carts are one thing, big client-server applications another. florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20011110/c0759ba7/attachment.pgp