Enterprise Applications: CMSC 838p Logistics, Study notes of Computer Science

Download Enterprise Applications: CMSC 838p Logistics and more Study notes Computer Science in PDF only on Docsity!

Enterprise Applications

CMSC 838p

Logistics

• Check with me if you aren’t officially registered - need a mailing list
• homework 1 due Wednesday
  • in class; bring a print-out

Class organization

• Small class
• I expect activate participation and help in developing course material
• SnipSnap page is a group effort
  • I expect you to provide content

Infrastructure

• mysql database on verve
  • temporary measure
• 4 dual-processor x86 linux boxes
  • 2 have arrived, 2 more expected next week
  • just for our class
• Other resources available:
  • 24-processor, 24 gigabyte Sun SMP
  • various larger clusters
• Access to prerelease builds of Java 1.

What is an enterprise

application?

Enterprise applications

• E-bay
• Amazon
• Campus course registration system

More features

• Distribution and scaling
  • some enterprise applications may be deployed in low activity environment
  • should be possible to scale them if demand warrants it
  • often means distribution across multiple machines
  • often geographically distributed
• Resiliency to failure
  • one machine failure cannot shutdown an enterprise application

Databases

• Relational databases the standard mechanism - scales well to very large data sizes - handles transactions and failure well
• SQL the standard language for talking to them

Persistent Objects

• It is a pain to have to use SQL queries whenever you want to touch persistent state
• Better to have objects that reflect persistent state - and can check integrity rules and other business logic

Persistent Object solutions

• EJB (Enterprise Java Beans)
  • BMP - Beans managed persistence
  • CMP - Container managed persistence
    • AppServer provides mapping between beans and database
• Java Data Objects
  • Good for small stuff

Transactions

• Atomicity - indivisible set of actions

• Consistency - respects database invariants

• typically domain specific

• Isolation - ignorant of other, uncommitted

transactions

• Durability - persistent, even in case of system

failure

A song database

• Album: albumID title category year
• Artist: artistID name - Song: songID albumID title length - Performance: songID artistID

Locking

• Transaction 1 reads current balance
  • sees $
• Transaction 2 reads current balance
  • sees $
• Transaction 2 adds $
  • sets current balance to $
• Transaction 1 adds $
  • sets current balance to $

How to handle

• In threads, we would just use locks
• In databases, can use pessimistic or optimistic concurrency - pessimistic concurrency similar to standard locking - optimistic: don’t lock - fail when committing if anyone else changed data you depended on