Hi All, Currently the IdentityEventHandler architecture doesn't use any special design technique to access/modify (identity and non-identity) claims. Also each handler is self-contained and is expected to work independent from other handlers. Both of these reasons are causing performance issues due to the fact that each handler goes to the database layer and does small transactions to retrieve/store few claims. In some cases the same claim might even be accessed/modified by multiple handlers, not knowing the fact that it may have been already loaded/modified by a previous handler.
Due to this recently we are seeing some performance issues in our lab tests. If we don't need some of those handlers in the system, we can disable them and see some performance improvement. But in the case all the handlers are needed we don't seem to have any other option. I believe the Unit-Of-Work pattern can address this issue because of the following features. 1. It maintains lists of business objects in-memory which have been changed (inserted, updated, or deleted) during a transaction. 2. Once the transaction is completed, all these updates are sent as one big unit of work to be persisted physically in a database in one go. What do you guys think? We need to have a wider discussion on how best to design and implement this, but I think the requirement is strong enough that we may need to prioritize this for one of the upcoming major releases. Thanks & Regards, Johann. -- *Johann Dilantha Nallathamby* Senior Technical Lead - WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
