However, after a few conversations on IM, Twitter (@arkzoyd), and the blog, I'm now convinced I made it wrong. I should have started by the beginning instead of pushing those programs with no explanation. I should have talked about the reasons why it's important to track message positions. How subtle XStream actually is. What benefit you could get from XStream compared to what use to exist before.
I'll try to correct the current situation and provide simple answers to the questions below:
- What is Oracle Streams?
- Why could you not get to the same result before XStream?
- What problem does it solve?
- Why is it cool?
- How does XStream relate to GoldenGate?
- What does Oracle want to do with XStream?
- How does XStream work?
- How can I know more about XStream?
What is Oracle XStream?
XStream is a new way to interact between Oracle Streams and the outside world. It uses a publish subscribe model that is different from the regular AQ queuing model. The purpose is to provide the same kind of features Oracle uses to propagate messages between databases to the outside world.As a result, with XStream, you can now propagate messages between a database and a program written in OCI or Java/OCI. In addition, you can guaranty that:
- no messages are written on disks, everything stays in memory during the propagation to and from the program; and not only you can guaranty that behavior between the database and your program but also to the whole chain of programs from the source to the destination of your messages
- If something crashes whether it's a database instance or your program, you'll be able to recover all your messages, in the right order and without loosing a single one
Why could you not get to the same result before XStream?
There are 2 cases, XStream addresses: (1) Inbound messages and (2) Outbound messages.- Inbound messages
Obviously you could also decide to enqueue your messages into a non-persistent queue on the staging database and use a propagation job to send the message to its destination database. The problem with that method is that there is no guaranty that, if an instance crashes, the message will ever go to its destination; otherwise, non-persistent queue would be called persistent queues!
To both guaranty the message to get to its destination, without the price of turning it persistent on the staging databases, until Oracle Database 11g Release 2, you could not rely on any Oracle database built-in... But now, you have XStream!
- Outbound messages
You could also turn your messages into non-persistent messages; yes, it's possible, if say, you create an apply handler that enqueue the message in a buffered queue. In that case, there is no guaranty you will never loose any message.
Like for Inbound messages, there is no built-in feature of Oracle you could use to guaranty a message from inside a database could be send to a destination outside the database without turning it into a persistent message on the staging database.
What problem does it solve?
As you can now guess, XStream enables you to propagate Streams messages between Oracle databases and the outside world in an extremely efficient way. It allows to propagate messages in-memory only (in most cases!) and, at the same time, it guaranties messages will be delivered to their destination.Why is it cool?
Because Streams is cool! And providing the power of Streams to the outside world is VERY cool, don't you think? ;-)How does XStream relate to GoldenGate?
XStream, like Oracle Active Data Guard is included into the GoldenGate license. But opposite to Active Data Guard, XStream cannot be licensed separately from GoldenGate. For now that's the only link between XStream and GoldenGate, even if we can guess GoldenGate could leverage the XStream feature sooner or later.What does Oracle want to do with XStream?
That's actually a very good question and I assume we can only guess for now. There is a bunch of things Oracle could do with XStream, like the ones below:- leveraging the technology in GoldenGate more than just by a bundle
- leveraging the technology for existing features of the Oracle Database like the In-Memory Database Cache or Oracle Coherence
- leveraging the technology to build new features like file to database integration or mySQL to Oracle integration (If we consider mySQL could turn into an Oracle offer one day soon).
- probably many more things I cannot even think about...
How does XStream work?
XStream relies on a few facts:- Messages are consumed once on the destination; whether they are made persistent or not doesn't actually matter. Once consumed a message on the destination will never be requested again.
- There is an order in the messages; in addition, there is a raw value that strictly increases and uniquely identifies the message positions in that order
- If a message is lost in the chain, that's because the chain has broken; and, in that case, all the subsequent messages are lost too.
- The message order is kept during the propagation from the source to the destination
- Messages are persistent on the source; Or, saying it in another way, if the destination doesn't get a message, the source will be able to resend it and in the same right order... Assuming it gets back the message position where to restart at!
- In the case of XStream Inbound, the program gets the last position from the server and then enqueue its messages from that point. On a regular basis, it gets some feedback from the server saying what messages are consumed on the destination and can release those messages from the source
- In the case of XStream Outbound, the program sends the last position of the applied messages and then dequeue messages from that point. On regular basis, it provides some feedback to the server saying what messages are consumed to allow the server to release them from its source.
Posts
No comments:
Post a Comment