Nader Mirzadeh wrote: > > We map collections to database tables and views. In order to have > transaction support we have to give each "database" object a connection, > thus there will be a one-to-one relation between databases and connections. > To have this model, DatabaseManager actually creates databases and not only > returns an already registered database. Hence, DatabaseManager API should > allow to register the DatabaseFactory objects that will be used by > DatabaseManager when the getDatabases() method is called (actually this > method returns new database objects).
Would changing the mapping slightly solve the problem? What if you mapped into a hierarchical set of collections where the top level collection is simply the container for all other collections? So you're basically replacing what you now have in database with a special type of collection. There is no reason that the collection impl returned by your Database impl. has to be the same collection impl that is returned by a Collection itself. Your top level collection can then manage all your resources including transaction control. I think this is pretty much what you're asking for. Database is already a factory but it is a factory for Collection objects. Collection is also a factory but it is a factory for child collection objects. Let me know if I'm not making sense. > Otherwise, if a database owns a pool of connections, there will be > different connections for different collections; and transaction brakes down > when there are several updates on the collections! > > Regards > Nader -- Kimbro Staken The dbXML Project http://www.dbxml.org/ ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
