While desirable at a business level this undermined the previously clear

While desirable at a business level this undermined

This preview shows page 12 - 14 out of 18 pages.

While desirable at a business level, this undermined the previously clear logical layering of Sonata: requiring reflection or similar workarounds to call into modules "upwards" up the dependency heirarchy, and (more seriously) introducing a new possibility of DAO PBX DAO calling; this last point causing numerous impacts, both obvious and subtle, on Context and Transaction Management. 8.1 Calling Patterns Infrastructure classes are now available to assist with nested calling: 'NestedCalling' class – assists in creating appropriate ApplicationContext/ SBS CallerDetails, based on the current SQLB Context. note this depends on ContextAnywhere and correct Tier setting to work. Setting Tier, don't set Tier first ServiceFactoryLookup.getPojoInstance()/ ServiceFactoryPOJO – obtains Service instances. 8.2 Obsolete/ Anti-Patterns Prior to the introduction of ServiceTemplate & standardized SBS entry/ exit, DAO sites calling SBS often attempted to "hack up" context manually. Today these patterns are undesirable, unnecessary and typically cause outright problems. Avoid the following patterns when calling SBS from DAO: do not manipulate the Tier manually. (TierUtils.enterTier()/ leaveTier()) do not check or attempt to use ApplicationContext from the DAO tier. do not check ApplicationContext or ApplicationContextFactory.isContextAvailable() from the DAO tier.
Image of page 12
Global Engineering (internal) – Java Code Architecture Overview Transaction Management 13 9 Transaction Management Transaction management in Sonata is a complex picture, which has evolved from rudimentary beginnings & encountered challenges as new features and paradigms have been added. While the worst have been resolved, it is to be understood as an area of significant challenge. 9.1 Application-Level APIs for Transaction Management Feature code should always use higher-level APIs which expose Transaction Management features at more meaningful & portable level for application code to use. TxManagement offers Spanning Transaction features answers appropriate CallTypes for transactional use. DAOHelper getDAOThatRequiresNewTransaction() – call a DAO in a new transaction. getDAOInNewTransaction()– deprecated, do not use. Raw manipulation of CallTypes and contextual/ calling machinery in feature code was a huge historical problem. Much work has been done to clean Sonata feature code of this raw manipulation. Developers must avoid writing new code that returns to these bad old practices. 9.2 Low-Level CallTypes Much of Sonata's transaction management is controlled by 'Call Types', and these were the original mechanism by which Remoting and Appserver Transactionality were implemented. The following Call Types are available. Commonly used ones are highlighted in bold: Usage Remoting DAO Call with Transaction DAO Call in New Transaction Client RDA HTTP Bean-Managed TX in Appserver BM BMAUTO deprecated Container-Managed TX in Appserver CM CMNEW Simple propagation of existing transaction PROPAGATE Standalone RDA
Image of page 13
Image of page 14

You've reached the end of your free preview.

Want to read all 18 pages?

  • Fall '19
  • Business logic, Business logic layer, sonata, global engineering

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture