embedded database

2 posts / 0 new
Last post
Anonymous
embedded database

hello guys. i am wondering about using the embedded derby database for our company which might have 1000 clients in the near future. is this a good approach or should i be better off with external DB. if external is a better option than whats the max client size for the embedded DB.

Another question is if the embedded db is keeping the user clients passwords in encrypted manner.

and lastly with the dmz and the session manager approach. What i wonder is that is there any documentation on how to install the session manager at the private network and the client connector manager in the dmz.

thanks/

Application: 

That's lots of questions. Some of them are not as straightforward to answer actually:

  1. For embedded database, the number of users in DB is not that important as the number of requests to the database. That is, how heavily it is used. So even number of online users is not a very accurate indication of the DB usage. More important is the user login/logout rate as this is when the DB is called. Generally I would say, up to 10k users in DB and up to 1 user loging/logout per second the embedded should do just fine.
    On the other hand, I always recommend not to use the embedded database for any production system. Support for embedded database was really added to make development easier, for a very small installations, small evaluation tests, etc...
    I used to have some problems with the embedded database (Derby) under a higher load with deadlocks. Therefore, if you only can, you should use external database.
  2. The way passwords are kept in the DB does not depend on the database you use. It depends on the settings in the DB actually and the authentication connector you use. Any supported password encryption can be used with any supported database. Moreover, you can connect the Tigase server to any database with custom schema and authenticate your users against data stored there. You do not necessarily have to use the Tigase own DB schema.
  3. I think there is no a guide specifically describing this. You should be able, however, to find enough information in existing documents to do that. If you have any problems, please let me know. Alternatively I could do that for you: