• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Bad Design leading to Bad Performance as data grows

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have inherited a legacy system.
basic architecture ....
  • Oracle DBMS
  • JPA/Hibernate
  • EJB3
  • JBoss 5
  • Struts 1

  • This single application has multiple(many) EJB Jars (which contain JPA entities) to access a singular database.
    As such if a WAR needs to access to data managed across say 3 EJB Jars, it has to compose the data from the three Jars before applying business logic and/or rendering of that data.

    Simple (worst case) example ...
    Setup of data....
    You have the following entities buildings, rooms, people.
    Buildings have multiple rooms, each room can house multiple people.

    Business logic...
    List all buildings(only buildings) with buildings in City A, Rooms on 2nd Floor, People with last name Smith.

    The current system is forced(at a minimum) to use the Buildings EJB to find all buildings in City A, The Rooms EJB to find all on the 2nd floor, and people EJB to find all with last name Smith, Then cross reference the lists (in essence do the joining) to determine the final list.

    Keep in mind this is all in the same database in which each EJB has access to all tables but only JPA Entities for the items it manages.
    Each EJB jar has it's own container injected EntityManager.

    MY QUESTION: Am I correct that the following would not be safe from a data integrity stand point?
    Have Building EJB execute a single query across Buildings,Rooms, and people to find the Buildings of interest.
    As I understand it since the Rooms and People are 'managed' by there own EntityManagers, there is no gaurantee of when data commits to those entity's tables will take place. As such the Buildings EJB may be querying against old data, because a single entitymanager is not used.





     
    Ranch Hand
    Posts: 417
    Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello,

    Having multiple jars can impact startup (first queries) performance but it otherwise has a negligible impact on performance and it is really common in big projects and I wouldn't consider it bad design.

    As per your data integrity concerns, I am not sure I understand your application setup correctly but in the end, a transaction manager can handle a single transaction even if multiple jar files are accessed in the process of one transaction. Even with different entity managers, it should be possible to keep everything transactional.

    Of course, your application design might still be sub-optimal but I wouldn't jump to conclusions too fast.

    http://www.byteslounge.com/tutorials/ejb-multiple-datasource-transaction-example

    http://www.kumaranuj.com/2013/06/jpa-2-entitymanagers-transactions-and.html
     
    A.J. Côté
    Ranch Hand
    Posts: 417
    Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Of course, if all tables are hosted in the same database engine, it is always more efficient to let the database do its work and use joined queries instead of merging the data at the application level.
     
    Kevin Embree
    Greenhorn
    Posts: 13
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I have come to discover that each EJB has it's own persistence unit. Am I wrong or doesn't each persistence unit have it's own caching and transaction management.
    If persistence unit A modifies table X and Persistence unit B modifies table X won't that lead to bad things?
     
    A.J. Côté
    Ranch Hand
    Posts: 417
    Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Yes potentially. I had a scenario where multiple applications were accessing the same database and I resorted to turn hibernate caching off to solve the issue.
     
    A.J. Côté
    Ranch Hand
    Posts: 417
    Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Can you easily manage to have all your EJBs use the same persistence engine?

    An obvious thing that comes to my mind is to have all EJBs retrieve the persistence engine through JNDI and define it at the application server level.
     
    Kevin Embree
    Greenhorn
    Posts: 13
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The persistence.xmls are generated as part of the Ant Build process. I should be able to tweak it with out much difficulting, I'm just worried that doing so will have some ill affect that I'm not thinking of. At some point someone that it necessary to give each EJB a different persistence unit. Question is out of ignorance or by design to address some need, that I am unaware of.
     
    A.J. Côté
    Ranch Hand
    Posts: 417
    Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You are correct. You will need testing/staging if you change anything. Does your application experience any faulty behavior right now?

    If it ain't broken maybe you would stay on the safe side by not fixing it. If it is broken, then get backup from management, propose and document your fix solution and test/stage to be on the safe side.

    Have you checked the current cache settings on your persistence units? Turning caching off if it isn't already off could be another option but test/stage anyway...
     
    reply
      Bookmark Topic Watch Topic
    • New Topic