Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Accessing data before commit

Re: Accessing data before commit

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: 19 Dec 2006 06:43:53 -0800
Message-ID: <1166539432.977545.27480@i12g2000cwa.googlegroups.com>

Ritvij wrote:
> My application has messaging interface with Stock Exchange for trade
> management.
> Consider my scenario:
> I send a message to other application X with Reference 'AAA' (Msg A).
> X can send two responses (Msg B : confirmation for Msg A and Msg C:
> Processing completion of Msg A), both with same reference 'AAA'.
>
> I need to process (always) Msg B and then Msg C for reference 'AAA'
>
> Consider scenario 1:
> X sends Msg B and then Msg C. I process Msg B and then Msg C. No
> problem!!
> Scenario 2: X sends first Msg C , then Msg B.
> I check Msg C, check that for reference 'AAA' no Msg B is received. I
> park the message C in a pending_process table.
> Then I process Msg B, process it, I check in pending_process table , if
> any Msg C is pending processing for 'AAA'. I process it. Again, no
> problem
>
> Scenario 3:
> X sends both B and C together. I use Tuxedo as transaction manager.
> Both B and C start getting processed in parallel by two different
> tuxedo processes.
> Msg C is processed and since Msg B is still not completed processing, I
> again park in pending_process. Howevever, the comit is still not done.
> While processing B, I need to check if any Msg C is pending, but since
> Msg C is not committed, I do not see.
> I do not process Msg C .,, Big Problem !!!!
> What do I do??
>

I recommend finding an appropriate database model for your application that doesn't require any kind of reading of "uncommitted data". What you are describing sounds like a fairly generic stock exchange setup which I am sure has been solved hundreds/thousands of times in relational systems.

You could have 4 separate tables 1 that holds the state of the transaction and separate tables for each of the messages you describe or 2 tables with some kind of status in the 2nd table that indicates what message type is . I am not recommending that setup or design it's just a quick thought.

Potentially it sounds like you could use advanced queueing but that also has ( like anything ) advantages and disadvantages. What you have described so far doesn't appear to require it but perhaps could be implemented with it.

If you are really responsible for the design of this application and you don't have an appropriate depth of design experience in financial stock manipulation systems then it's time to do some serious research and thing about contracting with a firm that does have that skillset.

Is this a college project? Received on Tue Dec 19 2006 - 08:43:53 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US