Topic
  • 11 replies
  • Latest Post - ‏2012-12-13T21:31:22Z by SystemAdmin
sandeep138
sandeep138
11 Posts

Pinned topic Lombardi/Process Designer & Java Integration

‏2012-07-17T15:43:47Z |
Hi,

I am trying to understand how Lombardi calls the Java integration component. When I select a class and its method, does it always create the new instance of the class and calls the method? What happens in case a static method is called from Lombardi?

I am trying to understand it so that if I can somehow make the number of Java object instances low, it will help little in performance.

Regards
Sandeep Jindal
Updated on 2012-12-13T21:31:22Z at 2012-12-13T21:31:22Z by SystemAdmin
  • kolban
    kolban
    3316 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-07-17T16:12:11Z  
    It is a good question. Here is how I look at it ... I would NEVER assume that a Java Object lives beyond the end of my Java Integration service call. As such, I always define my Java integration code to expose itself via static methods only. I never assume that the object lives after the first return. Obviously it depends on what you are doing, but I wouldn't be too concerned about the creation, usage and then immediate deletion of an object.

    Neil
  • sandeep138
    sandeep138
    11 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-07-17T17:46:25Z  
    • kolban
    • ‏2012-07-17T16:12:11Z
    It is a good question. Here is how I look at it ... I would NEVER assume that a Java Object lives beyond the end of my Java Integration service call. As such, I always define my Java integration code to expose itself via static methods only. I never assume that the object lives after the first return. Obviously it depends on what you are doing, but I wouldn't be too concerned about the creation, usage and then immediate deletion of an object.

    Neil
    Thanks Neil.

    I understand that the scope of the object created is 'local'. But, if we get to know how Lomabrdi would invoke java, we could look at some options, for example:

    1. Creating static methods (over simple public methods) because Lombardi may not create instance for that method call.
    2. Trying to explore we can use Singleton kind of pattern for Java Integration Invocation.

    Regards
    Sandeep Jindal
  • kolban
    kolban
    3316 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-07-17T18:06:23Z  
    Thanks Neil.

    I understand that the scope of the object created is 'local'. But, if we get to know how Lomabrdi would invoke java, we could look at some options, for example:

    1. Creating static methods (over simple public methods) because Lombardi may not create instance for that method call.
    2. Trying to explore we can use Singleton kind of pattern for Java Integration Invocation.

    Regards
    Sandeep Jindal
    Hi Sandeep,
    I would simply assume that a method should be exposed as static and assume that it is not allowed to persist references to objects it may have created between one call and the next. I would not even assume a singleton pattern would be safe. For example, imagine a BPD where Step A runs on one machine and Step B happens to be run on a second Process Server. You should make no assumption that multiple steps of the same process should even run on the same machine.

    Neil
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-12T21:39:12Z  
    I agree for data that's transactional in nature it is not a good idea to share Java objects between transactions, but for some Java objects just their metadata can be quite large. For example, Jaxb contexts are expensive to create, but I've heard they are thread safe. To me it would make since to me to us a singleton manager class to manage the Jaxb objects even if the BPM environment is distributed. The users will not have to wait, which could be several seconds, for new instances of the objects to be created.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-12T21:43:12Z  
    I agree for data that's transactional in nature it is not a good idea to share Java objects between transactions, but for some Java objects just their metadata can be quite large. For example, Jaxb contexts are expensive to create, but I've heard they are thread safe. It would make since to me to us a singleton manager class to manage the Jaxb objects even if the BPM environment is distributed. The users will not have to wait, which could be several seconds, for new instances of the objects to be created.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-12T22:27:59Z  
    I agree for data that's transactional in nature it is not a good idea to share Java objects between transactions, but for some Java objects just their metadata can be quite large. For example, Jaxb contexts are expensive to create, but I've heard they are thread safe. It would make since to me to us a singleton manager class to manage the Jaxb objects even if the BPM environment is distributed. The users will not have to wait, which could be several seconds, for new instances of the objects to be created.
    A new instance of the object is created for each invocation of the integration connector. (Which invokes a single method)

    Specifically, the default constructor is called in order to create a new object. If there is no default constructor, a non-obvious error will be thrown and the call will fail.

    So, the net is that you can have either static or non-static methods, but there isn't a whole lot of advantage to non-static methods since the invocation is effectively stateless.

    David
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-13T18:33:52Z  
    A new instance of the object is created for each invocation of the integration connector. (Which invokes a single method)

    Specifically, the default constructor is called in order to create a new object. If there is no default constructor, a non-obvious error will be thrown and the call will fail.

    So, the net is that you can have either static or non-static methods, but there isn't a whole lot of advantage to non-static methods since the invocation is effectively stateless.

    David
    David,

    I found away around the, "A new instance of the object is created for the integration connector": I wrapped the singleton manager with an outer object that isn't a singleton. The first transaction is slow, but the next transactions are fast. I use the singleton to manage thread safe objects that are expensive to create in the JVM.

    Scott
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-13T18:35:04Z  
    David,

    I found away around the, "A new instance of the object is created for the integration connector": I wrapped the singleton manager with an outer object that isn't a singleton. The first transaction is slow, but the next transactions are fast. I use the singleton to manage thread safe objects that are expensive to create in the JVM.

    Scott
    David,

    I found away around the, "A new instance of the object is created for the integration connector": I wrapped the singleton manager with an outer object that isn't a singleton. The first transaction is slow, but the next transactions are fast. I use the singleton to manage thread safe objects that are expensive to create in the JVM. For my situation, the transactions using the singleton manager are 20x faster, sub second, and 10 to 15 seconds without it.

    Scott
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-13T18:44:40Z  
    I know my singleton T created to manage expensive java objects is not stateless because I started WAS in debug mode and attached my Eclipse IDE to and saw it work. It grabbed an existing object form the memory map. Caching is modern programming. That's where you get your speed.
  • kolban
    kolban
    3316 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-13T19:15:40Z  
    I know my singleton T created to manage expensive java objects is not stateless because I started WAS in debug mode and attached my Eclipse IDE to and saw it work. It grabbed an existing object form the memory map. Caching is modern programming. That's where you get your speed.
    Your phrase of "Caching is modern programming" put a smile on my face. Caching is as old as the hills. In an ideal world, the notion of caching should be transparent to the consumers (end users and programmers who build the solution). Look at the Java Connector Architecture (for example). JCA has the concept of creating "pools" of expensive things, handing you one when you need it and then, when you claim you don't need it any longer, JCA cleans it up for re-use by the next person that comes along. All of this occurs transparently to the programmer who basically says "Give me XXX".

    With the latest WAS that is supplied with IBM BPM, we now have "Distributed object caching" via DynaCache technologies ... see:

    http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tdyn_distmap.html

    The bottom line is that no-one is saying that caching is a bad thing but how that caching is achieved is the core question of interest. From an IBM BPM perspective, we should assume that a call into an integration service will call Java and that when the call returns from Java ... nothing about the state of the thread or object references used by the thread should be considered to be present at the subsequent invocation. This does not say we can't use caching ... but what it does say is that we must use some architected technology that acts as a cache manager. Simply creating an object and attempting to keep a reference to it is not an "architected" exposed mechanism for maintaining information. The fact that experience may show that it might mechanically work is not the same as finding the "right" way of doing it.

    For example, in Java EE servlets, one is not allowed to maintain references to objects ... instead one assumes that the servlet is stateless. I think the best we can say about a Java Integration call is that it is stateless too. I'd look into the caching technologies provided by WAS and JPA to see if one of these can be leveraged.

    Neil
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Lombardi/Process Designer & Java Integration

    ‏2012-12-13T21:31:22Z  
    David,

    I found away around the, "A new instance of the object is created for the integration connector": I wrapped the singleton manager with an outer object that isn't a singleton. The first transaction is slow, but the next transactions are fast. I use the singleton to manage thread safe objects that are expensive to create in the JVM. For my situation, the transactions using the singleton manager are 20x faster, sub second, and 10 to 15 seconds without it.

    Scott
    I found away around the, "A new instance of the object is created for the integration connector": I wrapped the singleton manager with an outer object that isn't a singleton.

    Well, yes, however there are some challenges with this. The most notable is that you have no guarantee that both calls will happen on the same cluster node, nor are they guaranteed to happen within any guaranteed time period. It is very likely that they will happen on the same node in rapid succession, but in some cases (most notably failover), the second invocation may happen on a different node in the cluster after some time has passed.

    So if you are stuffing your expensive objects in a cache somewhere, you either need to use a distributed cache that you trust, or you need to account for the fact that there may be missing and/or out of date versions of your cache.

    Which, combined with the earlier comment about caching being modern programming (which, like Neil, also made me laugh) reminded me of the old Phil Karlton quote "There are only two hard problems in computer science: cache invalidation and naming things." Which I bring up because this workaround (while perfectly valid, and I've done it myself) can open up a number of cans of worms. I believe the whole reason that the Java connector works the way it does is because a BPM process is always inherently asynchronous by nature. And so anytime you assume that you will preserve state you are potentially going to have to worry about these kinds of issues.

    In the majority of cases, I'd say that if you are worrying about optimizing these kinds of things you are putting too much technical infrastructure in the BPM layer. But, in the minority of cases where you have no choice, there's nothing wrong with this kind of caching solution assuming you are willing to handle to complexity of the edge cases. (Which as Phil Karlton notes, are substantial.)

    David