Empire-db deliberately does never store a connection. Instead connection and transaction management must be performed on a higher application level.
For Web applications e.g. a typical scenario is that a http request marks a transaction, which consists of a number of database operations. The whole transaction is then committed if the request as a whole succeeds. In this case a connection is usually fetched from a connection pool that is maintained by the application server at the beginning of a request (or when first needed) and returned to the pool afterwards in order to allow hundreds of requests to be processed in short period of time. In that scenario Empire-db cannot know what belongs to a transaction or not and when it starts or when it ends. Typically is it sufficient to create an instance of your database object at application scope and use it as a singleton. Multiple threads may now use the database object simultaneously with different connections and transactions. Also you can be sure, that Empire-db cannot do anything "hidden" with the database as only methods that are provided with a connection can actually perform an operation. At application level you might want to handle that differently, depending on the needs of your app. Another concept of Empre-db is that you should make heavy use of subclassing. In your derived Database class you can store the connection if you wish (good for single-threaded applications) and overload database functions that require a connection and supply the one you have stored. So in fact, the aim is to provide a tool that does the basics and with maximum transparency and control rather than having a huge persistence System (e.g. like JPA, Hibernate) that do all kinds of magic things that you cannot fully control and that might not suit your needs. Regards, Rainer > from: Rainer Pruy [mailto:[email protected]] > to: [email protected] > re: DBReader.open() needs connection? Why? > > Hi, > > as a novice to empire-db, I just came across the fact that for getting > "larger" results, you should use a DBReader. > > The API doc suggests using "DBReader.open(DBCommandExpr cmd, Connection > conn)" > > However, why would one need to specify a connection when the underlying > database instance has been opened already > > and the DBCommand has been created from that database instance? > > While I can see some use cases for executing a query using a different > connection from the one the database has been opened with, > > I would expect the regular case be to open the database instance and then > execute queries against that opened instance. > > > Do I miss some fundamental aspects of empire-db? > > BTW: Is there some additional documentation that illustrates some more > aspects of the logical design than what is illustrated with the web page > > (Empire-db, Empire-db and Struts and Documentation sections)? > > > Regards, > > Rainer
