struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Hunter" <ihun...@hunterweb.net>
Subject Re: [newbie]dbcp pools with Struts... the saga continues
Date Wed, 26 Mar 2003 14:19:26 GMT
Maybe have them share a database connection, but use different databases
within that database server.  I'm not that familiar with Postgres, but
here's the idea as applied to SQL Server (Oracle would be similar)

1)  They subscribe, and your app copies everything it needs to get running.
A new database is created called "acme" (where do you store the customer's
name, "acme" in this case?  I'm assuming it's available to the app somehow).

2)  In your code to get an actual connection, you get the datasource via
JNDI, then the first statement executed is "use acmeDB"

3)  Proceed as before, and now they are using their own database.

Another option would be doing multitenancy in the tables, so everyone shares
the same database (there are advantages and disadvantages to this; you could
have *some* groups with access to other groups' data, if that's appropriate)

Going the other direction philosophically, yet another option would be
creating a new DB login for each customer, and the DB specifies which
database they have access to (e.g. "acme" login has default database =
"acmeDB" and "widgetco" login has default database = "widgetcoDB").  You
would have to set the username and password in the datasource before getting
the connections, and I'm not sure exactly how/if that would work, but it
would imply another layer of "security" in a way...

----- Original Message -----
From: "Johan Wasserman" <Johan.Wasserman@mgxgroup.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Sent: Wednesday, March 26, 2003 9:01 AM
Subject: RE: [newbie]dbcp pools with Struts... the saga continues


Problem is, as soon as a new company subscribes, I have automated
processes to copy the app from [example] http://myweb.com/template to
http://myweb.com/acme and create the relevant .propperties and .xml
files, etc... I even automate the creation of the new "acme" database
from a postgres template database.  I can automate the addition of a
datasource in server.xml, but then the server needs to restart and I
cannot automate the addition of another constant in my Constants class.

-----Original Message-----
From: Ian Hunter [mailto:ihunter@hunterweb.net]
Sent: 26 March 2003 15:48
To: Struts Users Mailing List
Subject: Re: [newbie]dbcp pools with Struts... the saga continues

You should be able to set up multiple database connections in
server.xml; I
don't see why there's a problem.  As long as you're using unique names
for
the resources, you should be OK.  BTW, a "standard" for naming such
things
would be "com.mycompany.myapp.Constants.DATABASE_KEY" -- not likely to
ever
step on someone else's resource name that way.

I have a Tomcat instance with two separate dbcp pools set up now, where
one
application uses one of them, the another uses the other, and everything
is
happy.

----- Original Message -----
From: "Johan Wasserman" <Johan.Wasserman@mgxgroup.com>
To: <struts-user@jakarta.apache.org>
Sent: Wednesday, March 26, 2003 3:40 AM
Subject: [newbie]dbcp pools with Struts... the saga continues


Hi,
This might me out of context, but please be patient with me.

I am now building a DAO (thanks for putting me on the right track Mr.
Graham) and I'm trying to find a way for the DAO to establish it's own
connection to the database pool/s created by the ActionServlet.
Again, I must stress that I am very new to struts and dbcp.  I would
prefer not to pre-established connection (using getConnection) and
passing that to the DAO, and I believe the method I'm trying to use
below should be helpful in a lot of other circumstances as well.

I know that would be very easy if my pool/s where configured in
server.xml and then would be accessable through initialContext.  But
being configured in strust-config (servlet context) I cannot set up a
<resource-ref> for it in web.xml.  (in servlet and not container
context, because multiple companies share the same web-server, but have
their own app connecting to their unique db instance).


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message