Unique Web Application

Discussions

General J2EE: Unique Web Application

  1. Unique Web Application (9 messages)

    Hi all,

    I'm working for an organization that has a 'J2EE' application deployed on Websphere with one catch; the only component of the J2EE specification that it uses are Servlets. All other components (business layer, data access, etc) are plain vanilla classes with yet another catch: 90% of the methods of each class are static.

    Could someone explain some of the ramifications of a large amount (200,000+ lines - a fair sized code base) static methods in vanilla classes on the server-side?

    I'm looking for reasons how it would affect performance. Any other comments would be greatly appreciated by anyone else that has been in the same situation.

    Cheers,

    Glenn

    Threaded Messages (9)

  2. Unique Web Application[ Go to top ]

    The static methods aren't so much of a problem. The issue is whether or not they are modifying any static data. Is this happening? If so, what kind of data is being defined statically?
  3. Unique Web Application[ Go to top ]

    The static methods aren't so much of a problem. The issue is whether or not they are modifying any static data. Is this happening? If so, what kind of data is being defined statically?


    They are not modifying static data.

    Have you run into similar issues? If so, did you manage to move to an EJB model? My boss has a hard time seeing the benefit of porting the static vanilla classes to a true server-side approach using EJB.

    Thanks for the reply.
  4. Unique Web Application[ Go to top ]

    Frankly I'm having a hard time seeing it too...it sounds as though you have very few business objects to render as EJB's and it is not clear what (if any) client state exists for you to hold in a session. J2EE is an architecture for managing business and conversational state, but most of what you have seems to be purely computational. Have you done an architectural analysis? If so, what architectural mechanisms have you identified that point to J2EE in this case?
  5. Unique Web Application[ Go to top ]

    Frankly I'm having a hard time seeing it too...it sounds as though you have very few business objects to render as EJB's and it is not clear what (if any) client state exists for you to hold in a session. J2EE is an architecture for managing business and conversational state, but most of what you have seems to be purely computational. Have you done an architectural analysis? If so, what architectural mechanisms have you identified that point to J2EE in this case?


    We actually have a large number of business objects, and _definetely_ a large amount of client state. We are a large payroll provider in Canada.

    I am doing architectural analysis now, and from what I'm seeing it could definetly benefit from some of the basic functionality provided by the J2EE model (most notably connection and transaction management as it it currently a bottle neck as well as a pain to deal with). Not to mention the endless amount of legacy integration that is required.
  6. Unique Web Application[ Go to top ]

    I don't see any major issues relating to thread performance with your static methods - since they only reference local variables they should not need to synchronize on anything. It's transaction management that is going to be the issue...
  7. Unique Web Application[ Go to top ]

    I don't see any major issues relating to thread performance with your static methods - since they only reference local variables they should not need to synchronize on anything. It's transaction management that is going to be the issue...


    You are exactly correct. This is our current scenerio:

    1.'Persistence' Layer is responsible for obtaining a pooled Connection and
      beginning a transaction.
    2. The Connection is then passed as an argument to the Business Facade, which is in turn passed to each object that is required to process the request. This is how we define a 'unit of work'.
    3. Once the business objects have finished processing the request, the Persistence layer commits the transaction.

    Without question the above approach is a serious bottleneck, as we tend to have a lot of concurrent users and connections are held for far to long.

    So with that being said, I'm trying to come up with a design that has minimal impact on the current code base that will allow us to avoid passing around the connection through the entire business object layer.

    Do you have any recommendations?
  8. Unique Web Application[ Go to top ]

    No suggestions? There has to be some options out there for the connection/transaction management issue?

    Thanks in advance,

    Glenn
  9. why not DataSource[ Go to top ]

    since your bottleneck is at acquiring Connection,why not using DataSource.
    configure a DataSource in AppServer and the pool size will automatically fit
    for the requests.
  10. Transactions...[ Go to top ]

    Does the code use local JDBC transactions or JTA transactions?

    Just curious.

    (Are you using XA DataSources?)