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) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Mon, Feb 5, 2018 at 10:58 AM, Zheng Feng <[email protected]> wrote: > 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 the other backends ? > > 2018-02-03 14:27 GMT+08:00 Willem Jiang <[email protected]>: > > > 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 > > authentication check before the connection. > > > > > > Willem Jiang > > > > Blog: http://willemjiang.blogspot.com (English) > > http://jnn.iteye.com (Chinese) > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Fri, Feb 2, 2018 at 10:55 PM, Zheng Feng <[email protected]> wrote: > > > > > 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 <[email protected]>: > > > > > > > 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 <[email protected]> > > wrote: > > > > > > > > > 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 > > transaction > > > > > events and user can view all events pass through pack and have a > peek > > > of > > > > > other transactions' flows which will be a serious security problem. > > > > > > > > > > > > > It's make sense that we add tenant or application id for separating > > > > transactions between two different application or users. > > > > > > > > > > > > > > > > > > *2. encrypted transportation between alpha and omega* > > > > > Currently, we use plain gRPC channel to communicate between alpha > and > > > > > omega. However, when it comes to production environment, users may > > want > > > > > more secure transportation options. Settings of gRPC transportation > > > > should > > > > > be configurable. > > > > > > > > > > As alpha can invoke the omega compensation operation, it's > important > > > to > > > > make sure that omega connects to the right alpha server . > > > > > > > > > > > > > > We will solve the above security concerns ASAP in the next release. > > Any > > > > > solution to the above security concerns is welcome. Besides, are > > there > > > > any > > > > > other security concerns we miss? Welcome to point them out. Thanks. > > > > > > > > > > > > > > > Best Regards! > > > > > Eric Lee > > > > > > > > > > > > > > >
