Hi Oliver,
1. Where should I store the db-connection parameters. Now I have
integrated it to service.xml! It works fine, but if I make the
deployment of the services I generate an ".aar" file which includes
also the service.xml. This implicates, that by updating the service on
a server, the service.xml is also overwritten, it means the
customer-settings (like db connection parameters, etc.) are lost and
have to set again.
Is there a better place to store such settings?
Do you really want to allow your customers to change DB connection
parameters? This doesn't look like a very good decision.
Anyway, if they can change them, then you must put them somewhere
outside the database, i.e. in file system. Since you overwrite .aar file
each time you deploy your service you could use some other place in the
file system.
2. I connect to db in the startUp method of an additional service-class
implementing the ServiceLifeCycle interface and stores it to a
service-parameter (the disconnecting is made in the shutDown method).
So from the serveral service-methods I can acces the db-connection
object over the servicecontext. It runs well.
Now, my question is, was happens, if there comes several requests to
services wich used the db-connection from different clients at the same
time? I think there is only one db-connection object instance, so there
can occur access violations, isn't it?
Yes. You could use locking to prevent this. Even better, you could add
conncetion pooling to your application, plus, open the connection before
writing to database, and close it afterwards. Connection is a valuable
resource, and you shouldn't keep it open all the time.
Regards,
Ognjen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
