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

[Paul]

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.

 

[Ken Bloom]

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 Bloom

 

[Logan Capaldo]

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

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.

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.

3. 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]

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 Bloom

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!

 

[Clifford Heath]

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.

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.

 

[Ken Bloom]

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".

 

[Paul]

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?

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).