Rails q: Two-Phase Commit/Updatable View/Roles

I’m exploring learning RoR, then using it for a new start project. Been
reading allot of RoR comparisons to Java… I’m not formally educated
in
enterprise client/server and have some Q’s regarding some of what I’ve
read.

  1. Two-phase commit: The general tone I read was “if you need a
    two-phase
    commit, use Java.” What is a two-phase commit? When/Why/Where would I
    want
    it? Since I lived without it so far, I think I’m OK now, but I like to
    plan
    projects with potential for future growth. If someday I did have a
    business
    case for 2-phase commit, could I do something in RoR to meet that need?

  2. Can you scaffold in updatable views? I haven’t delved into code
    yet,
    which might answer this Q. The reading so far indicates RoR CRUD is
    table
    centric. Was wondering if a updatable view was interchangable with
    tables.

  3. User CRUD roles… are they best maintained by RoR, or by the db?

Regards.

On Tue, 17 Oct 2006 08:46:42 -0400, Paul wrote:

I’m exploring learning RoR, then using it for a new start project. Been
reading allot of RoR comparisons to Java… I’m not formally educated in
enterprise client/server and have some Q’s regarding some of what I’ve read.

  1. Two-phase commit: The general tone I read was “if you need a two-phase
    commit, use Java.” What is a two-phase commit? When/Why/Where would I want
    it? Since I lived without it so far, I think I’m OK now, but I like to plan
    projects with potential for future growth. If someday I did have a business
    case for 2-phase commit, could I do something in RoR to meet that need?

Two phase commit is a protocol for commiting a single transaction that
spans multiple databases. It’s supposedly difficult to do in Java too,
but
if you need it you can look into database middleware that can coordinate
distributed transactions so that it appears to your rails app as
though you’re only working with one database.

–Ken B.

On Tue, Oct 17, 2006 at 09:50:06PM +0900, Paul wrote:

I’m exploring learning RoR, then using it for a new start project. Been
reading allot of RoR comparisons to Java… I’m not formally educated in
enterprise client/server and have some Q’s regarding some of what I’ve read.
First you probably want to ask these questions on the ruby on rails list

  1. Two-phase commit: The general tone I read was “if you need a two-phase
    commit, use Java.” What is a two-phase commit? When/Why/Where would I want
    it? Since I lived without it so far, I think I’m OK now, but I like to plan
    projects with potential for future growth. If someday I did have a business
    case for 2-phase commit, could I do something in RoR to meet that need?

I don’t knoq=w what this is either :wink:

  1. Can you scaffold in updatable views? I haven’t delved into code yet,
    which might answer this Q. The reading so far indicates RoR CRUD is table
    centric. Was wondering if a updatable view was interchangable with tables.

I don’t know what DB you were intending to try this with, but from my
experience, you can sort of do it with views in postgres, but it is a
huge pita. I personally intend to avoid it in the future.

  1. User CRUD roles… are they best maintained by RoR, or by the db?

Based on how rails is setup, you almost have no choice but to have this
in the app and not in the db

HTH.

M. Edward (Ed) Borasky wrote:

Ken B. wrote:

Two phase commit is a protocol for commiting a single transaction that
spans multiple databases.
Two-phase commit is what makes transactions have the ACID properties!

No, you’re thinking of two-phase locking, which is necessary for ACI
(not D)
only. Two-phase commit is a means of coordinating distributed
transactions,
as Ken said. Write-ahead logging is how most DB’s provide the “D” of
ACID.

if you need it you can look into database middleware that can coordinate
distributed transactions so that it appears to your rails app as
though you’re only working with one database.

Or use a DB that has the feature built-in. For example, in MS SQL
Server,
you can link-in a remote server to your main server, and then you can
run
transactions that span local and remote DBs. The distributed transaction
monitor interfaces with the SQL Servers through the standard XA, AX
protocols
and manages the 2-phase commit.

On Wed, 18 Oct 2006 00:39:20 +0900, M. Edward (Ed) Borasky wrote:

projects with potential for future growth. If someday I did have a business

Two-phase commit is what makes transactions have the ACID properties!
Lack of two-phase commit is a show-stopper for many database-backed
applications, and if Rails doesn’t support it somehow, I’d be extremely
surprised.

You’re thinking of two phase locking. Two phase locking ensures ACI in a
database (whether distributed or not), by acquiring all locks in a
transaction as you query/update the objects needed (the first phase),
and
by releasing them all at the same time[*] when you commit (the second
phase).

In two phase commit, the coordinator of a distributed transaction
queries
all of the distributed sites and asks them whether it’s safe to commit.
If
any veto the commit (or miss the timeout indicating that they have
crashed), the coordinator tells all sites to roll back. Otherwise, the
coordinator tells all sites to go ahead and commit.

–Ken
[*] the “same time” requirement technically makes this “strict two phase
locking”.

Ken B. wrote:

case for 2-phase commit, could I do something in RoR to meet that need?

Two phase commit is a protocol for commiting a single transaction that
spans multiple databases. It’s supposedly difficult to do in Java too, but
if you need it you can look into database middleware that can coordinate
distributed transactions so that it appears to your rails app as
though you’re only working with one database.

–Ken B.

Two-phase commit is what makes transactions have the ACID properties!
Lack of two-phase commit is a show-stopper for many database-backed
applications, and if Rails doesn’t support it somehow, I’d be extremely
surprised.

In any event, any reasonable DBMS that supports transactions should have
two-phase commit built in somehow. I’d recommend asking this question to
DHH and the Rails team – surely they can’t have ruled out Rails
applicability for transaction processing!

“Paul” [email protected] wrote in message
news:[email protected]

to meet that need?

  1. Can you scaffold in updatable views? I haven’t delved into code yet,
    which might answer this Q. The reading so far indicates RoR CRUD is table
    centric. Was wondering if a updatable view was interchangable with
    tables.

  2. User CRUD roles… are they best maintained by RoR, or by the db?

Bump.

I found some info pertaining to my Q. Cutpasted from
http://www.oracle.com/technology/pub/articles/saternos-rails.html:

“The use of Oracle’s “Inherently Updatable” views provides a useful
interface for taking advantage of ActiveRecord’s object-relational
capabilities. Again, these views serve to format the table structure and
data in a form that is most useful for Rails access. They also isolate
the
rails application so that there is increased auditing visibility for the
Rails database user and other application users that access the HR
schema.
All the power of Oracle SQL, including Oracle’s extensions to the
language
and functions, can be leveraged using find_by_sql.”

Seems Oracle is Rails freindly… and I have great respect for Oracle
db,
though am reluctant to use it because of price. (yes… I know it’s
free if
under 4GB… but I could see my app hovering around that barrier).