Mattias, One solution could be to mirror your database-per-client set-up in the app server. I seems that defining a new client is accepted to be a heavy-weight task. Maybe it could then be managable to create a database AND deploy the ear per client? You could easily automate the process using ant. Each time you deploy the standard ear (the archive for a complete enterprise application), the ant script would have to manipulate the vendor-specific deployment descriptor for the contained ejb module, in order to assign a dedicated data source (which would also have to be created by the automated deply process ) as well as the client-specific jndi bindings. This way you would have to construct a vendor-specific (app-server-vendor) deployment process, but your application could be 100% standard J2EE.
I'm not sure that the solution covers for your requirements of concurrent updates from batch and on-line traffic. Do you have some more details on the character of the batch jobs? /johan Den 02-08-01 12.54, skrev "Mattias Jiderhamn" <[EMAIL PROTECTED]>: > Hi all subscribers. > Joined this list to be able to discuss this one question. I have spent a lot > of thought on this and I'll try to describe things rather detailed, so try > to bear with me. > > We are developing a web application in Java with extensive database use. We > have one "general", system database (SYSTEM) with texts, user info, settings > etc. Every user of the system is associated to "clients" (usally the company > where they work). Most users have only one client but some have several. A > client can have "unlimited" number of user (mostly < 5) associated to it. > There can be unlimited number of clients (currently ~30). > Ex: > User1 has access to client 1 > User2 has access to client 1 and 53 > > Every client has their own database with their data. When a user loggs in > s/he is associated with the database of a) the only client s/he has acces to > or b) the client s/he chooses for the session. > > Today we are not using EJB or any third party middleware but only our own > proprietary solution. We have one application in the J2EE server (Resin) > with one connection pool to our MySQL database (initially the SYSTEM > database). I have built a wrapper around Resins connection pool so that when > a thread requests a connection, the connection is first switched to the > correct database, with MySQLs "USE database" command, depending on the user > of the session running the thread as mentioned above. There are also some > other features to handle transactions etc. > > Much of the use is through the web interface, where the data is fetched from > the database, put into hashtables and output on the page. But there are also > lots of background work, for which we have classes mapping to records in our > database tables. > > The biggest problem I see here is with caching. Since we have no object > cache we have to read the object from the database every time we use it, and > write it to the database every time we change it. Since we also read > directly from the database a lot, we can not have an object cache. I would > like to have the same interface for both "background" and "web" (both being > object oriented), but then we need to solve the performance issue. > > I have thought about EJB many times. I have also looked briefly at other > solutions that allow object caching. But it always comes down to the same > problem: I can't see how to get it working with differens databases for > different users. And of course, how would the object cache know wich client > the user who updated an object was logged into, when it is time to write it > back to the database? > > > Does anyone have a solution for this? > I saw someone mentioning Webgain TopLink in another post > (http://www.jguru.com/faq/view.jsp?EID=421472), could someone expain how > that could be of any help? > > Summary of what we want: > - Multiple (structurally identical) databases (main reasons: maintance and > security) > - Database selected at run-time > - Object-Relational mapping with caching > - Preferrably a non-proprietary solution > > Mattias Jiderhamn > Expert Systems > [EMAIL PROTECTED] > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
