This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
RRS is part of z/OS and can be used by things running there to help manage two phase commit processing between things running on z/OS. Liberty on z/OS can manage two phase commit transactions without involving RRS the same way it manages when it isn’t running on z/OS. The trick is that the interaction between Liberty and the resource manager (say DB2) has to take place so that neither one takes advantage of the fact that they are both on z/OS.
Generally applications in Liberty access DB2 using either a type-2 or a type-4 connector. A type-4 connector is when the connection between application and database is done using TCP/IP. When done this way the whole of the two phase commit protocol is done over that TCP/IP connection.
A type-2 connection is done locally. Both sides have to be running on the same operating system image. Basically Liberty and DB2 are on the same LPAR. The type-2 connector doesn’t use TCP/IP, but instead just uses cross-memory services to ‘reach’ from Liberty directly into DB2. There’s no network communication involved. And actually the processing done ‘in’ DB2 is done on a thread (TCB) in the Liberty address space. And that turns out to be important.
If you use a type-2 connector to talk to DB2, then DB2 will look for an RRS context on the TCB it is running on. And RRS will be used to coordinate the two phase commit processing between Liberty and DB2. Which means if you want to use a type-2 connector to talk to DB2 you’ll need to enable the RRS feature in Liberty. That feature requires an Angel since the RRS APIs being used require authorization.
Should you use type-2 or type-4? Ah…that’s a whole other subject. There are actually quite a few pros and cons of each and, to some degree, it depends what is important to you. For example, type-4 will (because the DB2 processing offloads to the zIIPs) make more use of zIIP engines than type-2 (because the native cross-memory DB2 processing generally won’t run on the zIIPs). But type-4 uses more CPU overall than type-2 (there’s that whole TCP/IP layer involved, even though we might not actually go anywhere). So is it more important to get more zIIP usage or just use less CPU overall?
There’s also an availability question. With type-2 you are (mostly) tied to the local DB2 instance (although you could have more than one) while a type-4 allows you to get to any DB2 instance in the datasharing group (i.e. across the sysplex). If you’re worried about DB2 dying on one LPAR and the Liberty server on that LPAR now having problems because it can’t get to a back-end database, then maybe type-4 is better for you. But when was the last time a DB2 instance just died on you? Still, it happens..
But back on subject, the point of this post was that Liberty integrates with RRS to enable the use of RRS coordinated two phase commit processing when Liberty is going to be involved in transactions with local resource managers via cross-memory connections <breathe>.