Moving the completed transactions to another backend could introduce
complexities on the transaction view layer.
Maybe we can just build up tables which is separated by the time (such as
week or month).
Just my two cents.
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
h
It makes sense here. So we store the transaction events in the database now
and do not delete them even if they are completed totally.
I think it would be an issue if the transaction events become more and
more. is it possible to only store the in-flight transactions and move the
completed ones to
Current we just need to provide a Restful service interface for the
transaction event view. Customer can build their own UI on the top it.
But for the omega and alpha communication, it's better to have the tenant
and application id for supporting multiple user application and having an
authenticat
Does the user view the transaction events through the restful service of
the alpha server ? I think we need an authentication mechanism rather than
the tenant or application id.
The gPRC looks like to support the SSL/TLS.
2018-02-02 21:04 GMT+08:00 Willem Jiang :
> Willem Jiang
>
> Blog: http://w
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Feb 2, 2018 at 4:44 PM, Eric Lee wrote:
> Currently, there are two known security concerns in Saga pack:
>
> *1. multi-tenants support*
> When pack
Currently, there are two known security concerns in Saga pack:
*1. multi-tenants support*
When pack is deployed in a cluster, access to transaction events should be
limited to those have the corresponding permission. Without any
restrictions to that will cause chaos in the management of transactio
