Use of transaction managers

Hi,

I am wondering how many transaction managers I should create and where they should live. I want to create transaction managers in the location where the network traffic between the client, the space partitions and the transaction manager is kept to a minimum.

Given the following requirements:
- components in processing units have to transactionally modify their partitions
- components in processing units have to transactionally modify their spaces
- external clients have to transactionally modify spaces

Below, p is the number of partitions and c is the number of external clients.

PU component transactionally modifying partition

The first requirement is easy to implement, so I have no questions about it (p partition tx managers per space):
<os-core:space id="space" url="/./space" />
<os-core:local-tx-manager id="transactionManager" space="space" />
<os-core:giga-space id="gigaSpace" space="space" tx-manager="transactionManager" />

PU component transactionally modifying space

For the second requirement do I:
- create a transaction manager in each processing unit (p cluster tx managers per space):
<os-core:space id="space" url="/./space" />
<os-core:distributed-tx-manager id="clusterTransactionManager" />
<os-core:giga-space id="clusterGigaSpace" space="space" tx-manager="clusterTransactionManager" clustered="true" />
- create a separate transaction manager and look it up in each processing unit (1 cluster tx manager per space):
<os-core:space id="space" url="/./space" />
<os-core:jini-tx-manager id="clusterTransactionManager" lookup-timeout="5000" />
<os-core:giga-space id="clusterGigaSpace" space="space" tx-manager="clusterTransactionManager" clustered="true" />

If the second case is better:
- where and how do I start a separate transaction manager?
- how to start a separate transaction manager for each space to prevent transactions from spanning multiple spaces?
- how to prevent a separate transaction manager from becoming a single point of failure?

External client transactionally modifying space

For the third requirement do I:
- create a transaction manager in each processing unit (p cluster tx managers per space) and get a reference to one of these (or a failover proxy) in the client:
<os-core:space id="space" url="/./space" />
<os-core:distributed-tx-manager id="clusterTransactionManager" />
<os-core:giga-space id="clusterGigaSpace" space="space" tx-manager="clusterTransactionManager" clustered="true" />

PlatformTransactionManager ptm = ?;
GigaSpace gs = new GigaSpaceConfigurer(s).transactionManager(ptm).gigaSpace();
- create a transaction manager in each client (c cluster tx managers per space):
PlatformTransactionManager ptm = new DistributedJiniTxManagerConfigurer().transactionManager();
GigaSpace gs = new GigaSpaceConfigurer(s).transactionManager(ptm).gigaSpace();
- create a separate transaction manager and look it up in each client (1 cluster tx manager per space):
PlatformTransactionManager ptm = ?;
GigaSpace gs = new GigaSpaceConfigurer(s).transactionManager(ptm).gigaSpace();

For the first case:
- how to lookup one of the transaction managers in the processing units (or a failover proxy)?

The questions for the third case are the same as the questions for the second case of the previous section.

Thanks in advance for your help.

Regards,

Johan Stuyts

This thread was imported from the previous forum.
For your reference, the original is available here

asked 2009-08-19 03:28:20 -0500

jstuyts

1 ●1 ●2 ●2

updated 2013-08-08 09:52:00 -0500

jaissefsfex
1 ●1

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

Johan,
It is better to use the distributed-tx-manager when your transaction spans multiple partitions. There is no need to start such manually – it will be started automatically and will be hosted within the GSC.
If you are using an embedded space where the proxy clustered mode is true as you have with your “PU component transactionally modifying space” case , the business logic might deal with remote other partitions. In this case you should use the distributed-tx-manager.

With the External client transactionally modifying space case:
First – Your url should "jini:////space" and not "/./space" as you are interacting with a remote (clustered) space.
If your external client deployed as a PU you can use the distributed-tx-manager.
If your external client deployed as a stand alone non managed client – you should use an existing remote transaction manager that would be started manually (you can do that by running the startJiniTX_Mahalo or with the GSC by adding into it the startTM command) or start it within the client - I’m not a big fan of this approach due to the higher probability of the client process to fail compared to the lower probability of the GSC to fail.

Shay

answered 2009-08-19 12:04:21 -0500

shay hassidim

17548 ●10 ●14 ●17

edit flag offensive delete link

Comments

I understand I need a distributed transaction manager if I want to use transactions over the whole cluster. My question is how many distributed transaction managers do I need per clustered space? Should 1 be enough for all PU components and remote (PU and non-managed) clients, or should 1 transaction manager be instantiated in each PU and in each client process (PUs and remote clients)?

You said that a distributed transaction manager is started automatically for a clustered space. So line 4 and attribute 'tx-manager' in line 5 below are not needed?
<os-core:space id="space" url="/./space"/>

<os-core:local-tx-manager id="partitionTm" space="space"/>
<os-core:giga-space id="partition" space="space" tx-manager="partitionTm"/>

<os-core:distributed-tx-manager id="clusterTm"/>
<os-core:giga-space id="partition" space="space" clustered="yes" tx-manager="clusterTm"/>

If line 4 can be removed, how do I get a reference to the transaction manager of the clustered space so I can pass it to PU components? I want PU components to be able to start, commit and rollback transactions programmatically.

Also how do I make the distributed transaction manager available for lookup by remote (PU and non-managed) clients?
IJSpace s = new UrlSpaceConfigurer("jini:////space").space();
PlatformTransactionManager ptm = // What must go here to lookup the distributed transaction manager in the space?
// Is it needed to pass the transaction manager to the configurer, or can the transaction manager be used without doing that because the GSC already knows about the link between the space cluster and the transaction manager?
GigaSpace gs = new GigaSpaceConfigurer(s).transactionManager(ptm).gigaSpace();

Sorry about all the questions, but I just want to make sure I do not instantiate more distributed transaction managers than needed.

I do still need to instantiate the local transaction manager if I want to access the partition transactionally, right?

Regards,

Johan

jstuyts ( 2009-08-20 07:03:13 -0500 )edit

You can run a distributed TX manger within each PU , or to have the same one to be used by all business logic components (collocated with the data or not). It does not matter. Having several of these running would not impact performance. I suggest you letting each PU to have its own distributed TX manger running and let the collocated code use it.

The <os-core:distributed-tx-manager id="clusterTm"/> obviously must be part of the pu.xml

You should have local TX manger for business logic that access one specific partition.

Shay

shay hassidim ( 2009-08-24 05:47:02 -0500 )edit

add a comment

Okay, I will create a distribute transaction manager for each cluster object: 1 in each PU instance and 1 in each external client.

Regards,

Johan

answered 2009-09-02 04:54:01 -0500

jstuyts

1 ●1 ●2 ●2

edit flag offensive delete link

Comments

cool, so one can use both a local transaction manager as well as a distributed transaction manager on the same PU. How do you specify which one to use using annotations?
We have quite some places we annotate as @Transactional (not event containers), but I can't find how to specify that that should be a distributed or local transaction then..

twessling ( 2009-09-16 11:30:26 -0500 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Use of transaction managers

PU component transactionally modifying partition

PU component transactionally modifying space

External client transactionally modifying space

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Use of transaction managers edit

PU component transactionally modifying partition

PU component transactionally modifying space

External client transactionally modifying space

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Use of transaction managers