Hi Firzhan, Does activiti documentation documents the CATEGORY_ column as a not used column. Otherwise there could be some usage of it, even though we have not encountered it yet. If the documentation states that the column is not used and is there for implementing extensions, then its fine to use it.
Otherwise, we should use another table to handle this. However, we should implement it in such a way that migration to new version of activiti should be straightforward. Regards Nandika On Fri, Sep 19, 2014 at 12:45 AM, Firzhan Naqash <firz...@wso2.com> wrote: > Hi All > > We have started to work on storing the artifact related version > information in to process DB. Initially we are going to implement it to > BPMN. > We have identified two implementable approaches. > > > 1. We can use the internal available ACT_RE_DEPLOYMENT table's CATEGORY_ > column to store the check-sum value. Currently actitviti engine itself > doesn't stamp any value at all. If we can use this column, we can > easily update and perform data migrations without any issue. But the > downfall of this approach is that, there is a probability for > this column being used internally for activiti's own implementation on > subsequent releases. > > 2. Next approach is to create a new table with in the activiti's database > schema. This table can be used to store information on versions. > But the downfall of this approach is, we have to extend some of the > classes to enable *mybatis* to load some of external mapping classes. > > Which way is the best approach to handle this scenario ? > > Regards, > Firzhan > > On Sat, Sep 13, 2014 at 1:58 PM, Nandika Jayawardana <nand...@wso2.com> > wrote: > >> +1 to remove storing versioning information storing from registry. The >> method of making the registry read only for worker nodes has added >> unnecessary complexity to bps clustering. It also has led to many support >> issues due to wrong configurations. By storing the versioning data also in >> the bps persistence db will reduce the configurations required for bps >> clustering in addition to providing easier maintenance and also likely to >> speedup the artifact deployment. >> >> Regards >> Nandika >> >> On Fri, Sep 12, 2014 at 11:30 PM, Firzhan Naqash <firz...@wso2.com> >> wrote: >> >>> >>> >>> Hi, >>> >>> In business process server, artifacts are deployed with a version number. >>> >>> In a clustered environment, in order to avoid the possibility of same >>> artifact having different version numbers assigned by both worker nodes and >>> master node, we have to make sure that only the master node is allowed to >>> assign a version number to an artifact where as other worker nodes have to >>> simply use it. >>> >>> This functionality is achieved in following way >>> >>> >>> 1. We stores the information like* md5 checksum* of a given artifact >>> along with other details like package name etc ... in *Registry.* >>> 2. Only the master node has R/W permission over Registry. Therefore >>> in order to detect the worker node and master node, we use the registry >>> mounting config value R/O or R/W. >>> >>> of This kind of storage pattern came to usage some time ago where we >>> used to store everything in registry. But on the other hand using registry >>> to store the artifacts have caused following issues. >>> >>> >>> 1. We have to maintain information about a given artifact in 3 >>> locations ( file system, persistence store, and registry ). >>> 2. While when we are on the process of deploying artifacts, server >>> might get killed. In this scenario, maintaining data in three different >>> locations may create inconsistencies. >>> 3. The same inconsistency may occur when either one of the storage >>> location get cleaned up. >>> >>> Therefore as a solution for this, we thought of storing the information >>> on artifacts in corresponding DB (BPS_DB) rather than storing them in >>> registry. >>> >>> Your thoughts and ideas are welcome. >>> >>> Regards, >>> Firzhan >>> >> >> >> >> -- >> Nandika Jayawardana >> Senior Technical Lead >> WSO2 Inc ; http://wso2.com >> lean.enterprise.middleware >> > > -- Nandika Jayawardana Senior Technical Lead WSO2 Inc ; http://wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
