Hi All, *Problem * Currently, some artifacts like userstores , tenants' data, etc are stored in the file system (not in the database). So when using a clustered setup those artifacts should be shared among all the nodes by using one of the following file sharing mechanisms.
- Dep Sync - rSync - Shared File System *Solution * In order to avoid a shared file system and to reduce the deployment and maintenance overhead, those artifacts ca be persisted in the database itself. *Approach* After discussing with @Ruwan Abeykoon <ruw...@wso2.com> and @Isura Karunaratne <is...@wso2.com> we have two options to persist above discussed artifact details. - In the configuration store which is already implemented as discussed in [1][2]. - In a separate table structure. If we are to go with option 01, then we need to consider the artifacts as configurations and persist in the existing schema. The advantage of using this is we can re-use the existing implementation including the database schema and existing rest APIs and functionalities (pagination, searching, etc) . The drawback is the conceptual difference between an artifact and configuration. Further if we are to use the configuration store there is no way to include specific input validations for the userstore configuration feature. If we are to go with the option 02, then the flow will be as follows. *Existing Flow* [image: Untitled Diagram (9).png] *Suggested Flow* [image: Untitled Diagram (10).png] - With the suggested approach, as the storage mechanisms, file system and database can be used and any other storage mechanism is pluggable. - There should be a way to identify the repository where the data is loaded from. The repository can be the file system, database or any other storage mechanism. - In both the read write operations the enduser should have the control to decide the storage mechanism. - If the user needs to migrate a userstore from one storage mechanism (file system) to another then they can do it via UI. When persisting the data in the database there are two options we can use : - Persist data as a blob - Persists data as key value pair If we are to go with the option one then we can persist the file as a blob and reuse most of the existing parsing logics. Highly appreciate your suggestions and feedbacks on the above approach. [1] [Architecture][IAM][JDBC based Configuration Store] Database Schema [2] [Architecture] [IS] JDBC based Configuration Store for WSO2 IS Thanks, Hasanthi -- Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc. (m) +94718407133 | (w) +94112145345 | Email: hasan...@wso2.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
