Transcript Converting Your Data Access Layer

Migrating JEE Apps to GigaSpaces
Case Analysis – Spring PetClinic
Uri Cohen, Product Manager
Sept. 24th, 2008
Agenda
• Background & Motivation
• What’s In an App Server
• Migration in Practice
– Messaging
– Data Access
– Web front end
• Architectural Considerations
• Live Demo
Background
• GigaSpaces as an application server
• Previous projects to map the migration
efforts and gaps
Motivation
• Feasibility study, learn about:
– User experience (migration complexity)
– Gaps between JEE & GigaSpaces
– Use that as input for next releases planning
• Share outcome with user community
– Provide a common basis for compatison
– “Here’s how it should be done with
GigaSpaces”
What’s In an App Server?
• Data access
• Messaging / event processing
• Remoting
• TX management
• Web
Migration in Practice
• Messaging / event processing
– Replace MDBs with GigaSpaces event listeners
• Remoting
– Replace SLSBs with GigaSpaces SVF (Remoting/Executors)
• Data access
– Use GigaSpaces 2nd cache for Hibernate
– Convert your DAOs to use GigaSpaces, use mirror to persist
• TX management
– Use Spring…
• Web
– Use GigaSpaces web processing unit
– Use GS HTTP session replication
Migration in Practice
Converted
Layer
Code change
Config
change
(3 is biggest)
Messaging
Minor to none
Yes
1
Remoting
No
Yes
1
Yes
2-3
No
1
Data Access
Web
(Http Session)
• ORM 2nd level cache: No
• DAO: Yes
No
Effort
Converting Your Messaging Layer
• Convert you MDBs to GigaSpaces event
containers
• You can use IMessageConverter on the client
side
• You can use annotations / XML
• Considerable performance boost
– Without affinity: up to 3 times faster
– With affinity: up to 6 times faster
Converting Your Messaging Layer
Converting Your Messaging Layer
Converting Your Remoting Layer
• Usually implemented by SLSBs with JEE
• No or minor code changes needed
• You get:
– Location transparency
– Dynamic service discovery
– Synchronous or asynchronous invocation
– Cluster wide invocations (Map/Reduce)
– Data affinity
– Automatic failover
Converting Your Remoting Layer
• Service Interface
• Client:
• Server:
Converting Your Data Access Layer
• Currently this is not effortless
• 1st step: Domain model
– Dealing with relationships
• Need to change domain model
– Add foreign key fields, update setter, O/R mappings
(if you use mirror)
• No lazy loading
– Load on a per case basis, might mean you should
change the DAO
• No object navigation and aggregations in queries
– Need to query the space multiple times and
aggregate
Converting Your Data Access Layer
• 2nd Step: Partitioning
– You should determine how objects will be partitioned
– May involve duplicating parent routing fields to
nested objects
• 3rd Step: Changing the DAO
– Naive approach: Convert all JDBC/Hibernate calls to
space calls
– Better approach: Use Remoting/Executors, take
advantage of data affinity and collocation
Converting Your Data Access Layer
• Other issues:
– Non String IDs: need to create cluster-wide ID
generator
– No dirty checks: similar to lazy loading, need to
persist on a case-by-case basis
– Semantics:
• When saving with Hibernate/JPA, generated ID is
injected into the object
• Solve at the DAO level
Architectural Considerations
• Web app & space in the same PU
– Partitioned or replicated?
– Is it really collocation?
– No dynamic scaling
• Web app & space in separate PUs
– Separate scaling models – more flexible
– No collocation
• Local cache can help
Let’s See It in Action
Future Roadmap (Suggestions)
• Object navigation in queries
– user.address.street=’Oxford’
• Native aggregate functions
– max, min, avg, std, custom
• Relationships
– JPA support
• Embedded EJB container?
Q&A