پاورپوینت کامل Chapter 24: Advanced Transaction Processing 50 اسلاید در PowerPoint

توجه : این فایل به صورت فایل power point (پاور پوینت) ارائه میگردد

 پاورپوینت کامل Chapter 24: Advanced Transaction Processing 50 اسلاید در PowerPoint دارای ۵۰ اسلاید می باشد و دارای تنظیمات کامل در PowerPoint می باشد و آماده ارائه یا چاپ است

شما با استفاده ازاین پاورپوینت میتوانید یک ارائه بسیارعالی و با شکوهی داشته باشید و همه حاضرین با اشتیاق به مطالب شما گوش خواهند داد.

لطفا نگران مطالب داخل پاورپوینت نباشید، مطالب داخل اسلاید ها بسیار ساده و قابل درک برای شما می باشد، ما عالی بودن این فایل رو تضمین می کنیم.

توجه : در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل می باشد و در فایل اصلی پاورپوینت کامل Chapter 24: Advanced Transaction Processing 50 اسلاید در PowerPoint،به هیچ وجه بهم ریختگی وجود ندارد

بخشی از مطالب داخلی اسلاید ها

پاورپوینت کامل Chapter 24: Advanced Transaction Processing 50 اسلاید در PowerPoint

اسلاید ۴: TP Monitor Architectures (Cont.)Process per client model – instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions.Memory requirements are highMultitasking- high CPU overhead for context switching between processesSingle process model – all remote terminals connect to a single server process.Used in client-server environmentsServer process is multi-threaded; low cost for thread switchingNo protection between applicationsNot suited for parallel or distributed databases

اسلاید ۵: TP Monitor Architectures (Cont.)Many-server single-router model – multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.Independent server processes for multiple applicationsMultithread server processRun on parallel or distributed databaseMany server many-router model – multiple processes communicate with clients.Client communication processes interact with router processes that route their requests to the appropriate server.Controller process starts up and supervises other processes.

اسلاید ۶: Detailed Structure of a TP Monitor

اسلاید ۷: Detailed Structure of a TP MonitorQueue manager handles incoming messagesSome queue managers provide persistent or durable message queueing contents of queue are safe even if systems fails.Durable queueing of outgoing messages is importantapplication server writes message to durable queue as part of a transactiononce the transaction commits, the TP monitor guarantees message is eventually delevered, regardless of crashes.ACID properties are thus provided even for messages sent outside the databaseMany TP monitors provide locking, logging and recovery services, to enable application servers to implement ACID properties by themselves.

اسلاید ۸: Application Coordination Using TP MonitorsA TP monitor treats each subsystem as a resource manager that provides transactional access to some set of resources.The interface between the TP monitor and the resource manager is defined by a set of transaction primitivesThe resource manager interface is defined by the X/Open Distributed Transaction Processing standard.TP monitor systems provide a transactional remote procedure call (transactional RPC) interface to their serviceTransactional RPC provides calls to enclose a series of RPC calls within a transaction.Updates performed by an RPC are carried out within the scope of the transaction, and can be rolled back if there is any failure.

اسلاید ۹: ۹Workflow Systems

اسلاید ۱۰: Transactional WorkflowsWorkflows are activities that involve the coordinated execution of multiple tasks performed by different processing entities.With the growth of networks, and the existence of multiple autonomous database systems, workflows provide a convenient way of carrying out tasks that involve multiple systems.Example of a workflow delivery of an email message, which goes through several mails systems to reach destination.Each mailer performs a tasks: forwarding of the mail to the next mailer.If a mailer cannot deliver mail, failure must be handled semantically (delivery failure message).Workflows usually involve humans: e.g. loan processing, or purchase order processing.

اسلاید ۱۱: Examples of Workflows

اسلاید ۱۲: Loan Processing WorkflowIn the past, workflows were handled by creating and forwarding paper formsComputerized workflows aim to automate many of the tasks. But the humans still play role e.g. in approving loans.

اسلاید ۱۳: Transactional WorkflowsMust address following issues to computerize a workflow.Specification of workflows – detailing the tasks that must be carried out and defining the execution requirements.Execution of workflows – execute transactions specified in the workflow while also providing traditional database safeguards related to the correctness of computations, data integrity, and durability.E.g.: Loan application should not get lost even if system fails.Extend transaction concepts to the context of workflows.State of a workflow – consists of the collection of states of its constituent tasks, and the states (i.e. values) of all variables in the execution plan.

اسلاید ۱۴: Workflow SpecificationStatic specification of task coordination:Tasks and dependencies among them are defined before the execution of the workflow starts.Can establish preconditions for execution of each task: tasks are executed only when their preconditions are satisfied.Defined preconditions through dependencies: Execution states of other tasks. “task ti cannot start until task tj has ended” Output values of other tasks. “task ti can start if task tj returns a value greater than 25” External variables, that are modified by external events. “task ti must be started within 24 hours of the completion of task tj”

اسلاید ۱۵: Workflow Specification (Cont.)Dynamic task coordination E.g. Electronic mail routing system in which the text to be schedule for a given mail message depends on the destination address and on which intermediate routers are functioning.

اسلاید ۱۶: Failure-Automicity RequirementsUsual ACID transactional requirements are too strong/unimplementable for workflow applications.However, workflows must satisfy some limited transactional properties that guarantee a process is not left in an inconsistent state.Acceptable termination states – every execution of a workflow will terminate in a state that satisfies the failure-atomicity requirements defined by the dmitted – objectives of a workflow have been achieved. Aborted – valid termination state in which a workflow has failed to achieve its objectives.A workflow must reach an acceptable termination state even in the presence of system failures.

اسلاید ۱۷: Execution of WorkflowsWorkflow management systems include:Scheduler – program that process workflows by submitting various tasks for execution, monitoring various events, and evaluation conditions related to intertask dependenciesTask agents – control the execution of a task by a processing entity.Mechanism to query to state of the workflow system.

اسلاید ۱۸: Workflow Management System ArchitecturesCentralized – a single scheduler schedules the tasks for all concurrently executing workflows.used in workflow systems where the data is stored in a central database.easier to keep track of the state of a workflow.Partially distributed – has one (instance of a ) scheduler for each workflow.Fully distributed – has no scheduler, but the task agents coordinate their execution by communicating with each other to satisfy task dependencies and other workflow execution requirements.used in simplest workflow execution systemsbased on electronic mail

اسلاید ۱۹: Workflow SchedulerIdeally scheduler should execute a workflow only after ensuring that it will terminate in an acceptable state.Consider a workflow consisting of two tasks S1 and S2. Let the failure-atomicity requirement be that either both or neither of the subtransactions should be committed.Suppose systems executing S1 and S2 do not provide prepared-to-commit states and S1 or S