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
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
