Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only one transaction serializer is used regardless of contract config #225

Closed
millefoglie opened this issue Feb 13, 2022 · 1 comment
Closed

Comments

@millefoglie
Copy link
Contributor

Once any transaction is invoked, the corresponding transaction serializer will be used for all other transactions as well, regardless of what is set in a @Contract annotation. For example, if we call a method of contract A that uses a default JSONTransactionSerializer, and then call a method of contract B with a custom serializer, then JSONTransactionSerializer will be used in both cases. The reason for this is that within ContractRouter#processRequest creation of an ExecutorService via an ExecutionFactory always returns a singleton instance with one specific transaction serializer:

final SerializerInterface si = serializers.getSerializer(txFn.getRouting().getSerializerName(),
                        Serializer.TARGET.TRANSACTION);
final ExecutionService executor = ExecutionFactory.getInstance().createExecutionService(si);

Thus, the same serializer is used all the time, even though si here can be different.

millefoglie added a commit to millefoglie/fabric-chaincode-java that referenced this issue Feb 13, 2022
Fixes the issue of having a single transaction serializer in use for
all contracts regardless of configuration. The issue was due to
having a singleton instance of ExecutionService that had only one
associated serializer. Thus, the first used serializer was also used
for all other transactions. The fix removes this singleton and replaces
it with a ContractRouter field.

hyperledger#225

Signed-off-by: Bogdan Repeta <[email protected]>
@gqqnbig
Copy link
Contributor

gqqnbig commented Mar 8, 2022

looks like this issue can be closed?

@mbwhite mbwhite closed this as completed Mar 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants