Transactions from WIndchill client

[MartyRoss]

I'm trying to support a variable set of direct change operations (such as setting effectivity, updating lifecycle states and part attribute values) on Windchill PDMLink 9.1 M040 parts (WTParts and EPMDocuments) and I'd like to "sandwich" the operations inside a transaction block from a windchill client (i.e., Tomcat or a standalone RMI client).

I've tried using "trx = new Transaction(); trx.start(); myoperations(); trx.commit();" in an RMI client and am getting "wt.methodNo active mLifecycleState);", etc.)

From the APIdoc, it's not clear if this is the right way to do this, or what else I need to do to set it up right, if anything. Is "wt.pom.Transaction" even supposed to work client side? What is the best / correct way to do what I want?

Any pointers will be much appreciated!

[jessh]

wt.pom.Transaction is not supposed to work client side.

The Windchill Java API is not intended to support client demarcated
transactions.

Overall the recommended approach would be to locate such code on the
server and call it from the client.

[MartyRoss]

Thanks! Sure; code examples of - I imagine something like a
"TransactionService" I'd need to write - would be great!!

Marty Ross
Software Development Sr. Advisor
Dell | Services Healthcare
office +1 617 509 2029
martin_ross@dell.com
Harvard Pilgrim Health Care, 93 Worcester Street, Wellesley, MA 02481

Please consider the environment before printing this email.




"simonh@wincom-consulting.com" <simonh@wincom-consulting.com>
07/18/2011 05:02 AM

To
marty_ross@harvardpilgrim.org, -
cc

Subject

[jessh]

It's not that you'd normally write a "transaction service".

Rather if you had a transaction like:

trx = new Transaction();
try
{
trx.start();

// do lots of stuff

trx.commit();
trx = null;
}
finally
{
if ( trx != null )
trx.rollback();
}

you'd move all of that to the server and wrap it up as a new service API
or RemoteAccess class, so that from the client you'd end up doing
something like:

MyResult result = MyService.service.doMyTransaction( .... );

with various different (meaningfully named) doMyTransaction() methods
for each type of transaction you're doing, not one method for many.

[dtkach1]

Can you use just a java UserTransaction instead wt.pom.TransactionCan you use a distributed model like XA resources/transactions?

If you can point to some presentation or docs specifically it will be great.

[jessh]

Windchill does each transaction within 1 method server, not distributed
transactions across multiple method servers, e.g. using XA two-phase commit.

[MartyRoss]

OK, I get it. Thanks. Sort of defeats the purpose of my client layer -
to get away from having to touch the server code to satisfy the needs of
my custom jobs.
Now, what is "wt.container.batch"? It looks interesting judging from its
name, as one way to describe what I'm looking to build is a "batch
container" for handling an arbitrary set of modifications within a
transaction. I'd just need to define & code the "primary operations"
("assertions"?) supported by the server-side container, and the client
could queue them up in the order - and with the parameters - it needs for
its jobs.

Marty Ross
Software Development Sr. Advisor
Dell | Services Healthcare
office +1 617 509 2029
marty_ross@dell.com
Harvard Pilgrim Health Care, 93 Worcester Street, Wellesley, MA 02481

Please consider the environment before printing this email.




Jess Holle <->
07/18/2011 12:45 PM

To
marty_ross@harvardpilgrim.org
cc
"simonh@wincom-consulting.com" <simonh@wincom-consulting.com>,
-
Subject
Re: [solutions] - RE: Transactions from WIndchill client






It's not that you'd normally write a "transaction service".

Rather if you had a transaction like:
trx = new Transaction();
try
{
trx.start();

// do lots of stuff

trx.commit();
trx = null;
}
finally
{
if ( trx != null )
trx.rollback();
}
you'd move all of that to the server and wrap it up as a new service API
or RemoteAccess class, so that from the client you'd end up doing
something like:

MyResult result = MyService.service.doMyTransaction( .... );

with various different (meaningfully named) doMyTransaction() methods for
each type of transaction you're doing, not one method for many.

[jessh]

On 7/19/2011 12:15 AM, Marty Ross wrote:
>
> OK, I get it. Thanks. Sort of defeats the purpose of my client layer
> - to get away from having to touch the server code to satisfy the
> needs of my custom jobs.
Just having a client layer doesn't mean everything should occur there.

Placing transactions on the client has numerous downsides. One of these
is simply that there is unnecessary chatter between the client and the
server. For /ideal /client performance one should have at /most/ one
client/server round-trip communication (at least in series rather than
in parallel) per user action. In the real world one rarely maintains
this ideal, but having a client-side transaction is a clear violation of
this precept.

Another performance rule is that the minimum necessary data should be
communicated between client and server, which using a client-side
transaction also generally violates.

On top of this there is the complexity and overhead involved in properly
doing a client-demarcated transaction.
>
> Now, what is "wt.container.batch"? It looks interesting judging from
> its name, as one way to describe what I'm looking to build is a "batch
> container" for handling an arbitrary set of modifications within a
> transaction.**I'd just need to define & code the "primary operations"
> ("assertions"?) supported by the server-side container, and the client
> could queue them up in the order - and with the parameters - it needs
> for its jobs.*
> *
>
Yes, this package is an approach to this problem. I think most
Windchill developers see this and are attracted to it for a bit --
before deciding that it is far simpler and more maintainable in the long
term to expose new, clearly documented operations to the server to
support their client needs.

--
Jess Holle