Hi Nandika, Activiti documentation doesn't mention about the CATEGORY_ column. But they have provided a method to set values for the CATEGORY_ column. In future they may use the column for different purposes or they may deprecate this method.
Therefore as a safest option, we can use a new table to implement it. I will try to work on the migration issue as well. Regards, Firzhan On Fri, Sep 19, 2014 at 10:54 AM, Nandika Jayawardana <nand...@wso2.com> wrote: > 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
