1. Code simple, but not simpler
Discuss ways to develop enterprise
applications based on “POJOs in
Action” by Chris Richardson

2. Who am I?
Viachaslau Churukanau
Senior Software Engineer, Java world
Edmunds.com, room 404

3. INTRODUCTION

4. You have to design enterprise
applications at some moment
But how to develop this skill if:
• There are no appropriate trainings
• The Internet usually provides little,
contradictory and out of date knowledge
• People tell you “lie”
• Etc.
?

5. Correct Solution
Read Books and Try

7. POJOs in Action (2006)
• shows how to address many common and
complex design issues in back-end logic
development of enterprise applications with
fantastic real-world examples
• combines best practices and design wisdom to
integrate domain-driven design and test-driven
development for object-oriented applications
• carefully explains the techniques and
technologies used at various levels, including
Spring, JDO, Hibernate, EJB 3, and iBatis.

8. Key Messages
• Regardless of how the frameworks evolve,
there are some key concepts that will not
change
• Every technology has both benefits and
drawbacks
• Make everything as simple as possible, but
not simpler (Albert Einstein)

9. Design Decisions

10. ORGANIZING THE BUSINESS LOGIC

11. Domain Model (object-oriented)

12. Money Transfer Example

13. Benefits and Drawbacks
+ Improved maintainability and extensibility
+ Persistence framework enables you to easily
map the domain model to the database
- You should have good OOD skills

14. Transaction Script (Procedural)

15. Benefits and Drawbacks
+ Easy to Use (no OOD skill required)
+ Can use full range of SQL features
- Code can be difficult to understand and
maintain (complex business logic, explicit load
and save all required data)
- Cost of maintaining handwritten SQL (e.g. add
a column – change multiple queries)
- Lack of portability of SQL

16. When to Use
• The application must use SQL directly or you
cannot use a persistence framework
• The business logic is very simple
• The development team lacks the necessary
OO design skills

17. ENCAPSULATING THE BUSINESS
LOGIC

18. EJB session / POJO facade

19. Benefits and Drawbacks
+ Business Logic is encapsulated and is free of
transaction management (including distributed
transactions), security, remote access, detaching
objects, etc.
- You must write extra code
- It is quite easy for the detachment code and
the presentation tier to get out of sync and for
the POJO façade to only return some of the
objects required by the presentation tier

20. Exposed Domain Model (Open Session
in View)

21. Benefits and Drawbacks
+ Faster development (the business tier does not
contain façades or error-prone detachment logic)
- Less encapsulation (it is quite easy for business
logic to creep into the presentation tier; the
presentation tier has access to the domain objects;
business tier changes affect presentation tier)
- No support for remote access
- Tricky to configure interactions between
transactions, persistence framework, and the
servlet API

22. ACCESSING THE DATABASE

23. What’s wrong with using JDBC directly
• Developing and maintaining SQL is difficult
and time consuming
• There is a lack of portability with SQL
• Writing JDBC code is time consuming and
error-prone

24. What if I need SQL?
• You must use the full power of SQL, including
vendor-specific features, in order to get good
performance
• Your DBA might demand complete control over
the SQL statements executed by your
application
• The corporate investment in its relational
databases is so massive that the applications
working with the databases can appear
relatively unimportant

25. iBatis
• Insulates the application from connections
and prepared statements, iBATIS maps
JavaBeans to SQL statements using XML
descriptor files or annotations
• Supports for database-generated primary
keys, automatic loading of related
objects, caching, and lazy loading

26. Why you don’t want to persist objects
yourself
1. Lazy Loading (loading all of the objects that
might be accessed might be extremely
inefficient)
2. Writing back to the database only those objects
that have been modified (it would be extremely
inefficient to save all objects regardless of
whether they have changed)
3. The database access code must preserve object
identity by ensuring that there is a single in-
memory instance of a persistent object when
processing a request

27. Solution
Use ORM Framework

28. Кey features of an ORM framework
• Declarative mapping between the object model
and database schema
• An API for creating, reading, updating, and
deleting objects
• A query language
• Support for transactions
• Lazy and eager loading
• Caching
• Detached objects

29. Benefits and Drawbacks
+ Improved productivity
+ Improved performance
+ Improved portability
+- Sometimes you must use SQL directly
(performance, etc.)
- Challenging when you’re working with a legacy
schema (e.g. denormalized)
- You might design a domain model that cannot be
mapped to the desired database schema

30. HANDLING CONCURRENCY
IN DATABASE TRANSACTIONS

31. Read Phenomena

32. Isolated Database Transactions
• The database ensures that the outcome of
executing multiple serializable transactions is
the same as executing them serially.
• Serializable transactions prevent such
problems as lost updates and inconsistent
reads

33. Benefits and Drawbacks
+ They are simple to use
+ They prevent many concurrency
problems, including lost updates and
inconsistent reads
- They produce the high overhead, which can
reduce performance and scalability
- Fully isolated transactions can fail more
frequently than less isolated transactions
because of deadlocks and other concurrency-
related issues

34. When to Use
• Read consistency is essential
• The overhead of fully isolated transactions is
acceptable

35. Pessimistic locking

36. Benefits and drawbacks
+ Unlike optimistic locking, pessimistic locking does not
require any schema changes
+ It prevents a transaction from overwriting another
transaction’s changes
+ It reduces the probability of deadlocks in databases that
implement fully isolated transactions by locking rows
when they read
- All potentially conflicting transactions have to use
SELECT FOR UPDATE in order for pessimistic locking to
work, which is potentially error-prone
- Some databases have limitations on how SELECT FOR
UPDATE can be used

37. When to Use
• The database schema does not support
optimistic locking because, for example, the
tables do not have a version or timestamp
column or contain values such as floats or
blobs that cannot be compared
• The application requires some degree of read
consistency
• You don’t want to incur the overhead of
serializable transactions

38. Optimistic locking

39. Benefits and Drawbacks
+ It is easy to implement and it is supported by
many persistence frameworks
+ Unlike pessimistic locking, does not prevent an
application from using certain SQL SELECT
statement features
- All potentially conflicting transactions must use
optimistic locking or errors will occur
- No guarantee that a transaction will be able to
update the rows that it read
- Does not prevent inconsistent reads

40. When to Use
General recommendation is that an application
should use optimistic locking unless:
• The database schema does not support
optimistic locking
• The application must be guaranteed to be
able to update the rows that it read
• The application requires consistent reads

41. HANDLING CONCURRENCY
IN LONG TRANSACTIONS

42. Edit-style Use Case

43. What’s wrong with using a single
database transaction
• The database transaction would be long-
running because it encompasses multiple web
requests and user think time
• The transaction might last until the web
session timed out if the user could simply walk
away from the browser without completing
the use case
• It reduce scalability and concurrency

44. Pessimistic Offline Lock

45. Benefits and Drawbacks
+ Ensures that a user can save changes
- Impacts the application globally (don’t forget
to use it in a new code, etc.)
- Requires a mechanism to forcibly release locks

46. When to Use
• The probability of conflicts is high
• The consequences of conflicts are severe
• Users typically do not abandon their sessions
or it’s feasible to implement a lock cleanup
mechanism

47. Optimistic Offline Lock

48. Benefits and Drawbacks
+ It is relatively easy to implement
+ Unlike the Pessimistic Offline Lock pattern, there are no
locks to clean up if the user abandons the session,
which is not uncommon in a web application.
- Because the Optimistic Offline Lock pattern only detects
changes when the user tries to save their changes, it
only works well when starting over is not a burden on
the user
- All transactions that update shared data must increment
the version number whenever they update a row,
including those that do not use the Optimistic Offline
Lock pattern

49. When to Use
• The probability of conflicts is low and the
consequences of redoing the changes are
minimal
• Users regularly abandon sessions and you
don’t want to implement a lock cleanup
mechanism

50. Summary