Howdy, >I'm just wondering what's the "risky" part. Is database pooling any >different than this idea, in that you are still dependent on something >outside of Java mis-behaving and is platform-specific. > >And would there be anything "non-portable" except for the JNI part, which >of course is platform-dependent.
I suppose you could substitute platform-dependent for non-portable in my earlier statement. OS processes are a lot less uniform than JDBC implementations. Connection pooling has much stricter interfaces (namely java.sql.Connection, java.sql.Statement, java.sql.ResultSet, javax.sql.DataSource, javax.sql.PooledConnection) than java processes (java.lang.Process). As the JavaDoc for the Process class says, there are no strict constraints on when the process executes, how, etc. So yes, database pooling is different in practice if not in concept. The interfaces uses for database pooling are much stricter, designed for pooling, tested for pooling. The java.lang.Process is more of a necessary evil. I'm not saying your solution won't work, especially if it's constrained to and well-tested on a specific OS. But it's likely to require significantly more testing, if it's portable at all, to other systems. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
