Hi Pierre,
Unfortunately this will not work. RewriteRules are applied right
before SQL is submitted to the database by the BackendWorkerThread.
It's too late in the process to do transformations that affect locks.
I'm working on some changes to Sequoia to introduce the ability to
install interceptor classes at different points in the processing
flow. (See sequoia-963 for more information.) However, even with
this feature you must be very careful what sort of transformations
you undertake. Depending on when they occur you may or may not have
already collected metadata, which means we could end up locking the
wrong SQL objects. You can also end up invalidating previous parsing
decisions, so all in all the transformation problem is quite tricky.
Emmanuel's last comment seems the best summary--you really need to
choose whether to use tables or views. Otherwise it gets difficult
to avoid avoid deadlocks and/or inconsistent updates.
Cheers,
Robert Hodges, CTO, Continuent, Inc.
Email: [EMAIL PROTECTED]
Mobile: +1-510-501-3728 Skype: hodgesrm
On Sep 13, 2007, at 1:16 AM, BESSON-DEBLON, Pierre ((SOGETI HIGH
TECH)) wrote:
Thanks for answer,
Is it possible RewriteRules can save us ?
Queries from application which uses views could be rewrited. (i
have to study more deeply if it is possible with our views names).
But will locks work correctly in this case ?
Regards,
Pierre Besson-Deblon
-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] la part de
Emmanuel Cecchet
Envoyé : 13 September 2007 00:28
À : Sequoia general mailing list
Objet : Re: [Sequoia] oracle views
Hi Pierre,
We use sequoia with oracle sgbd,
2 applications are linked to sequoia, one uses TABLES and the
other uses VIEWS, some of this views are bidirectional (UPDATE
statements are available)
we succeed in starting controllers, requesting tables and views
configuring a static shema for the backend with a <DatabaseTable>
markup for each table or view of our schema.
In an another hand i have seen Raidb1 level implies a table
parsing. Though the explanation his duplication needs to acquire
locks on table when updates are requested...
1) Is this interpretation correct ?
Yes. Note that this should also work without a static schema if you
ask
views to be fetched in your virtual database configuration file.
2) Do we risk some database inconsistency with this
configuration ? (If first answer is yes, i'm afraid the second
answer is yes too :( )
If you are using Sequoia 2.x then yes, views are considered as
separate
tables. So if you update the view and try to access the tables, the
proper locking will not be done. In Sequoia 3.x, it is possible to
declare a view definition to tell which tables are accessed by a
view so
that Sequoia proceeds to the proper locking. However, it is my
understanding that Sequoia 3.x will not be developed further nor
supported.
3) If this configuration is risky, what other choice do we have ?
As long as you always update data the same way (always through the
view
or always through the tables), you should be fine. Reads should be
properly isolated with Oracle snapshot isolation whatever way you
access
them.
If you are updating concurrently through the view and the tables, then
you will have inconsistencies with Sequoia.
Hope this helps,
Emmanuel
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
This e-mail is intended only for the above addressee. It may
contain privileged information.
If you are not the addressee you must not copy, distribute,
disclose or use any of the information in it.
If you have received it in error please delete it and immediately
notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management
and security reasons. This access is controlled under Regulation of
security reasons.
This access is controlled under Regulation of Investigatory Powers
Act 2000, Lawful Business Practises.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
