Foundation APIs and Repository Internals
Upcoming SlideShare
Loading in...5
×
 

Foundation APIs and Repository Internals

on

  • 1,455 views

In this session we will start by examining some of features that developers have available when using the Foundation service interfaces: how to initiate and use transactions; how and when to make use ...

In this session we will start by examining some of features that developers have available when using the Foundation service interfaces: how to initiate and use transactions; how and when to make use of transactional resources; using different types of search; controlling behaviors e.g. 'cm:auditable'; changing CopyService behavior. Following this, some repository internals will be examined, including: typical content lifecycles and parameters that control these; schema generation files, upgrade scripts and runtime SQL (3.4-specific); considerations for large-scale custom data structures.

Statistics

Views

Total Views
1,455
Views on SlideShare
1,455
Embed Views
0

Actions

Likes
0
Downloads
61
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 1:00
  • 1:00Focus on development; Possible to pick up details from the Javadocs and proceed; I will give details of supporting infrastructure and considerations that will improve your code.
  • 1:00
  • 1:00
  • ~2:40Later demo: Write batching (demo 1)Note: 3.4
  • ~4:40
  • ~6:45Usually, user-driven changes are usually evenly distributed; more danger from server-initiated process (background processes or logic derived from customer events).
  • 10:30Yellow: Taking these limits other transactionsGreen: No effect on other transactions
  • 18:20Illustrate the difference between Implicit and Explicit transactions and why developers should care about themWill see how cost of continuing txn is negligible
  • 21:20
  • 23:45Demo 0Fewer CPU cycles
  • 29:45Demo 1Effects of index.tracking.disableInTransactionIndexing: that Mike Farman and I will be showing
  • 34:00Demo 2Can go into optimistic locking, but it is less prevalent on 3.4 as writes occur immediately, etc.
  • 43:00Leave non-propagating alone unless ...Use read-only for all read scenarios. If your code is writing in the reads, then change it. In an emergency, start a new transaction (non-propagating, but should use conditional logic.Will discuss an example later.
  • 47:00

Foundation APIs and Repository Internals Foundation APIs and Repository Internals Presentation Transcript

  • Alfresco Repository Internals
    1
    Derek Hulley
    Senior Engineer, Alfresco
    twitter: @derekhulley
  • Alfresco Repository Internals
    2
    Resource Contention
    Node Creation and Modification
    Actions
    Scheduled Jobs
    Transactions
    Resources
    Implicit and Explicit
    Using Alfresco’s Transaction Support
    Agenda (1)
  • Alfresco Repository Internals
    3
    Navigating Hierarchies
    Lucene-based APIs
    NodeService-based APIs
    Walking Child Associations
    Policies and Behaviour
    Policy Behaviour Filters
    CopyService
    Agenda (2)
  • Alfresco Repository Internals
    4
    Content Lifecycles
    ContentData Properties
    Binary Files and Transactions
    Orphaned Content
    System Properties
    Application Bootstrap
    Spring init
    Lifecycle Classes
    Modules
    Questions
    Agenda (3)
  • Resource Contention
    5
    Node Creation
    • Row inserts
    • Read-committed isolation: Invisibleuntil commit
    • Database, Caches, Lucene Indexes: Low contention
  • Resource Contention
    6
    Node Modification
    • Update type, aspects, properties, ACLs; Move; Delete; etc
    • Invisible until commit, but can hold resource locks
    • Transactions rejected e.g. ConcurrencyFailureException
  • Resource Contention
    7
    Actions and Scheduled Jobs
    • Danger of background jobs moving ‘up’ a hierarchy
    L1N1
    ?
    L2N1
    L2N2
    L3N1
    L3N1
    Only one winner (at a time)
    • Individual node modifications are serialized
    • Pick up small junks, commit and give way
  • Transactions: Resources
    8
    • Database row locking
    • ‘version’ column: optimistic locking
    • Each transaction requires a thread
    • Possibly multiple transactions on a thread
    Connection Pool
    Thread Pools
    • One transaction – one connection
    • Connection housekeeping has a cost
    Caches
    Transaction
    • Index deltas
    • Heavy on IO
    Lucene Indexes
    Content Binaries
    • New content binaries only
    • Temporary files
    Database Rows
    • Caches are transaction-aware
    • Conflicts drop cache entries
    It pays to think about resource contention.
    Replaying transactions means:
    • Reclaiming resources
    • CPU cycles
    • Lower response times
  • Transactions
    9
    Implicit
    • Defined against public service (Foundation) APIs
    • Bean naming convention: NodeServicevsnodeService
    • Cost is in starting a transaction, not continuing one
    • public-services-context.xml and ServiceRegistry
    • Spring customization and interceptors
  • Transactions
    10
    Explicit
    • Wrap all atomic operations including groups of reads
    • Use RetryingTransactionHelper rather than UserTransaction
  • Transactions
    11
    Explicit: Demo: Read-only Batching
    • Time lost to transaction initiation
    • 3ms lost per low-level operation ... How much per user click?
    Get Stores
    Get Children
    Lucene Query
  • Transactions
    12
    Explicit: Demo: Write Batching
    • Time lost to initiate transactions. Well, yes, but ...
    • Unnecessary additional indexing
    CIFS and FTP
    index
    Create Node
    Get Writer
    index
    Add Content
  • 1
    Transactions
    13
    Direct Contention: Demo
    begin
    0
    0
    1
    1
    1
    1
    1
    0
    0
    0
    log4j.logger.org.alfresco.repo.transaction.RetryingTransactionHelper=warn
    Eg: Retrying OptimisticLockingDemo-8: count 0; wait: 0.1s; msg: "Failed to update node 14575"; exception: ...ConcurrencyFailureException
  • Transactions
    14
    Alfresco Transaction Support
    • RetryingTransactionHelper
    • Reliable, resolves contention
    • “non propagating”: Transaction suspended and a new one started.
    • TransactionService.getRetryingTransactionHelper -> your instance
    • TransactionalListener and TransactionListenerAdapter
    • Bind to events associated with a transaction
    • AlfrescoTransactionSupport
    • Helper around Spring’s TransactionSynchronizationManager
    • getTransactionReadState: Allows logic conditional on the state of the transaction.
    • bindResource and getResource: Bind objects to current transaction. This is like ThreadLocal but is safer i.e. Resources are bound to the transaction and go away when the transaction is terminated.
    • TransactionalResourceHelper
    • <K,V> getMap(Object resourceKey), etc: Helper to get transactionally-bound collections.
  • Navigating Hierarchies
    15
    Lucene-Driven APIs
    • SearchService.query()
    • Versatile
    • Not always transactionally consistent
    • Cluster: Transactions are replayed for indexes
    SQL-Driven APIs
    • SearchService.selectNodes()
    • Fast for simple path-based searches only: e.g.:“/app:company_home/app:data_dictionary”
    • Always consistent!
    • NodeService.*
    • Use for consistent views
    • FileFolderService.*
    • Limited to cm:folder-based lookups
    • Fast lookups on cm:name (via NodeService)
  • Navigating Hierarchies
    16
    Walking Child Associations
    • Hierarchy traversal is fast if the child associations can be isolated.
    • Put the correct data into createNode
    P1
    • No uniqueness on path QName, but can be used to trim results to a meaningful few.
    • Use type QName for better search selectivity.
    • Use child associations that have <duplicate>false</duplicate> to enforce uniqueness (cm:name) and use FileFolderService.
    Child Association indexes:
    • Parent and child
    • typeQName
    • qname
    • Also unique cm:name
    N2
  • Policies and Behaviour
    17
    Policy Behaviour Filters
    • Temporarily disable polices
    • Bound to the currenttransaction
    • Bean: “behaviourFilter”
    cm:versionable
    • Prevent a change from forcing a new version
    • Force versioning on metadata change: cm:autoVersionOnUpdateProps
    cm:auditable
    • Manually set cm:modified date
    • Prevent cm:modified from being recorded
  • Alfresco Repository Internals
    18
    Application Bootstrap
    Server Startup
    • DDL script execution: lock table
    • Spring init(): no resources available
    • Alfresco Bootstrap: order of AbstractLifecycleBean
    • Module Bootstrap: module startup on AbstractModuleComponent
  • Q & A
    19