Module gaurds in Pact - pact-lang

With module gaurds, is it possible to insert to a table but not add a read function within that defined module that sits on a public chain (chainweb)...then subsequently define a module on scalableBFT (private chain) that allows an account defined on the permissioned network to read from the table sitting on the public chain? Possibly a privacy preserving method?

Related

WebModule in Delphi SOAP Application Server

Given that the each request message spawns a separate thread, and separate instances of the Web module and its contents are created dynamically for each thread, I added a FDConnection and FDQuery to the webmodule so that I can send a personnel profile from the database to the requester upon request.
How can I access a web module instance?
In the web module there is only one variable of the web module metaclass :
var
WebModuleClass: TComponentClass = TWebModule1;
for example:
WebModule.FDQuery.Close;
The CountryImpl unit is implementation of CountryIntf service
unit CountryImpl;
interface
uses Soap.InvokeRegistry, System.Types, Soap.XSBuiltIns, uCountry, CountryIntf,
WebModuleUnit1;
type
TCountryManager = class(TInvokableClass, ICountryManager)
public
function GetCountry(ACountryId: integer): TCountry;
end;
implementation
{ TCountry }
function TCountryManager.GetCountry(ACountryId: integer): TCountry;
begin
WebModule.FDQuery.Close;
WebModule.FDQuery.ParamByName('Id').Value := ACountryId;
WebModule.FDQuery.Open;
end;
initialization
InvRegistry.RegisterInvokableClass(TCountryManager);
end.
Your assumption is incorrect: Only 1 instance of the webmodule is created in the SOAP server application. You should not add thread-specific functionality to the webmodule, you must add it to the CountryImp.pas. Since there is no design-surface there, you have to do runtime instantiation of FDConnection(s) and FDQueries in the functions in that unit.

Thread safety in google endpoints and Objectify and how does allocateId works ?

I have an OfyService class of this type
/**
* Custom Objectify Service that this application should use.
*/
public class OfyService {
/**
* This static block ensure the entity registration.
*/
static {
factory().register(MerchantProfile.class);
factory().register(Product.class);
}
/**
* Use this static method for getting the Objectify service object in order to make sure the
* above static block is executed before using Objectify.
* #return Objectify service object.
*/
public static Objectify ofy() {
return ObjectifyService.ofy();
}
/**
* Use this static method for getting the Objectify service factory.
* #return ObjectifyFactory.
*/
public static ObjectifyFactory factory() {
return ObjectifyService.factory();
}
}
I use factory().allocateId() method to allocate Key (to get Long id) before saving an entity. I have a problem where I need to transfer money from one account to the other and add an entry to Transaction table. So, I use ofy().transact(new Work<~>) in the following way
WrappedBoolean result = ofy().transact(new Work<WrappedBoolean>() {
#Override
public WrappedBoolean run() {
}
}
I allocate Id for Transaction before entering the transact part and then I subtract money from one account add it to other and then save both the accounts and Transaction entity.
My concern is as follows
What happens when there are two concurrent requests and app engine Instance provide them separate request handlers and same ID is allocated to both of them, depending upon the database State or it is not possible that the same id gets allocated twice.
What is the flow of control of Work as compared to the conventional synchronization block that we use in Java for making critical sections?
PS: To perform the same in other frameworks like Jersey (with JPA) I would have used a Synchronization block and would have done the Transaction in that block. And since at a time only one thread can access that block and id is also assigned once data is saved to the table there would have bee no issues.
Thread safety is not relevant to data consistency with either the datastore or with JPA/RDBMSes. If you are relying on synchronization, you are doing something wrong.
If you create a complete unit of work that performs your task and execute it in a transaction, the datastore will ensure that it is either completely applied or not applied at all. It will also guarantee that all transactions behave as if they were operated in serial. This might result in any particular execution aborting and retrying, but you don't see this as a user.
In short: Just put this in a transaction and do not worry about threading.

How do I get a handle to the UVM factory?

I'd like to get a handle to the UVM factory so as to use function such as set_type_override_by_name().
The UVM factory uses the singleton design pattern to provide a handle. You get() a handle using the static get() method.
uvm_factory uvm_factory_h;
uvm_factory_h = uvm_factory::get();
uvm_factory_h.set_type_override_by_name("original_type_name","override_type_name");
etc.
You can directly use set_type_override_by_name method, without having uvm_factory handle.
For uvm_factory Handle -
Still, if you want to have uvm_factory class handle ,then you can use uvm_coreservice_t class to get uvm_factory handle.
The singleton instance of uvm_coreservice_t provides a common point
for all central uvm services such as uvm_factory, uvm_report_server
and so on.
The service class provides a static <::get> which returns
an instance adhering to uvm_coreservice_t. The rest of the
set_ get_ pairs provide access to the internal uvm
services
To get uvm_factory handle:
uvm_coreservice_t cs = uvm_coreservice_t::get();
uvm_factory factory = cs.get_factory();
factory.set_type_override_by_name(original_type_name,override_type_name, replace);
For more information, visit http://sourceforge.net/p/uvm/code/ci/UVM_1_2_RELEASE/tree/distrib/src/base/uvm_coreservice.svh

Using Objectify For retrieving from Datastore- Error :Did you forget to inherit required module

I am using Objectify for retrieving data From datastore in GWT,But i get the Following Error :
[ERROR] No source code is available for type
com.logins.entity.experts; did you forget to inherit a required
module?
I have Client->entity->Server and i did define the RPC properly with RemoteServicePath.
i intiaized the Rpc in client side
final findexpertAsync
finexp=(findexpertAsync)GWT.create(findexpert.class);
GWT compiler throws Error at the method i call,
finexp.expert(expnam, new AsyncCallback<ArrayList<experts>>()
Note:
1) findexpert and FindexpertAsync are the RPC interface which has a method for retriving data from datastore
2)com.logins.entity.experts:experts is a server class.
Any guesses where i am going wrong ?
All classes directly or indirectly referenced from the client must be part of the client source path. You can't access server-only code from GWT. In this case, class "experts" needs to be part of the GWT-compiled client code.
Also: You should capitalize Java class names.

Registering dependencies within TinyIOC for use in NancyFX

I have another newbie question regarding registering additional dependencies within TinyIoc for use within NancyFX.
I am continuing to get the following exceptions when running the application...
Unable to resolve type: AdvancedSearchService.Interfaces.IResponseFactory
Exception Details: TinyIoC.TinyIoCResolutionException: Unable to resolve type: AdvancedSearchService.Interfaces.IResponseFactory
Source Error:
Line 25: var container = TinyIoCContainer.Current;
Line 26:
Line 27: _responseFactory = container.Resolve<IResponseFactory>();
Line 28:
Line 29:
I am currently registering my dependencies incorrectly, but I cannot seem to figure out the correct way. Below is my code within my custom bootstrapper. Also note that I am not currently calling the base.ConfigureRequestContainer method because I cannot seem to figure out how to get the current context to pass into it.
protected override void ConfigureApplicationContainer(TinyIoCContainer container)
{
container.Register<IRavenSessionManager>(new RavenSessionManager());
base.ConfigureApplicationContainer(container);
ConfigureRequestContainer(container);
}
protected void ConfigureRequestContainer(TinyIoCContainer applicationContainer)
{
var requestContainer = applicationContainer.GetChildContainer();
requestContainer.Register<ISearchRepository>(new SearchRepository(requestContainer.Resolve<IRavenSessionManager>().GetSession()));
requestContainer.Register<IResponseFactory>(new ResponseFactory(requestContainer.Resolve<ISearchRepository>()));
//base.ConfigureRequestContainer(requestContainer,[I NEED THE CONTEXT])
}
Any help would really be appreciated...apparently my ignorance has no limits :)
Ok, not 100% sure where to start.. you don't need the context because you're doing it wrong :-)
Firstly, why are you calling "configure request container" at all, and why are you creating a child container? You don't do that :-) There are two scopes, application scope, configured by overriding ConfigureApplicationContainer, and request scope, configured by overriding ConfigureRequestContainer, you don't call them yourself, you just override them depending on how you want to scope your objects.
Secondly, the default Nancy bootstrapper will "autoregister" everything it can in its default implementation of ConfigureApplicationContainer. By calling "base" after you've made a manual registration you are effectively copying over your original registration by autoregister. Either don't call base, or call it before you do your manual registrations. And, again, don't call ConfigureRequestContainer from your ConfigureApplicationContainer :-)
If you don't care about everything being application scoped (so singetons get the same instance for each request) then you don't need any of this, you can just rely on autoregister.
You're currently constructing your objects manually and putting them into the container, that seems a rather odd way to do it. Normally you'd just register the types and let the container handle instantiating as and when it needs to.
You're not overriding ConfigureRequestContainer, you are just creating a new method (with a different signature).
So, what you probably want is something like:
protected override void ConfigureApplicationContainer(TinyIoCContainer container)
{
base.ConfigureApplicationContainer(container);
// Autoregister will actually do this for us, so we don't need this line,
// but I'll keep it here to demonstrate. By Default anything registered
// against an interface will be a singleton instance.
container.Register<IRavenSessionManager, RavenSessionManager>();
}
// Need to override this, not just make a new method
protected override void ConfigureRequestContainer(TinyIoCContainer container, NancyContext context)
{
// Get our session manager - this will "bubble up" to the parent container
// and get our application scope singleton
var session = container.Resolve<IRavenSessionManager>().GetSession();
// We can put this in context.items and it will be disposed when the request ends
// assuming it implements IDisposable.
context.Items["RavenSession"] = session;
// Just guessing what this type is called
container.Register<IRavenSession>(session);
container.Register<ISearchRepository, SearchRepository>();
container.Register<IResponseFactory, ResponseFactory>();
}

Resources