A Streams captured message could be turned into a persistent message which guaranty you will not loose your message but require you pay the price of turning captured messages persistent on the staging database. The principle is basically the same for outbound messages. 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. 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! 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. However, if the database you put your messages in isn't your message destination database, you would have to pay the price of turning messages persistent in that staging area. In both cases, Oracle database guaranties you will not loose your message. Why could you not get to the same result before XStream?There are 2 cases, XStream addresses: (1) Inbound messages and (2) Outbound messages.īefore XStream, to send a message to a database the simplest way was to make it persistent you could for example : "insert the message into a persistent queue" or "insert it into a table". In that case, you can turn them into persistent messages or you can slow down the capture or propagation processes. Obviously, if you face some bottleneck/saturation, you may decide, like Streams does internally, that it's more efficient for your messages to spill out of memory. 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.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.The purpose is to provide the same kind of features Oracle uses to propagate messages between databases to the outside world.Īs a result, with XStream, you can now propagate messages between a database and a program written in OCI or Java/OCI. It uses a publish subscribe model that is different from the regular AQ queuing model. What is Oracle XStream?XStream is a new way to interact between Oracle Streams and the outside world. If you have some high level questions about XStream, feel free to comment this post If you have technical issues, I suggest you directly post on the Streams Forum. What does Oracle want to do with XStream?.Why could you not get to the same result before XStream?.I'll try to correct the current situation and provide simple answers to the questions below: What benefit you could get from XStream compared to what use to exist before. I should have talked about the reasons why it's important to track message positions. I should have started by the beginning instead of pushing those programs with no explanation. However, after a few conversations on IM, Twitter ( and the blog, I'm now convinced I made it wrong. I really wish those 2 programs can help people. I have written 2 programs a few months back to use and experiment Oracle XStream when I discovered Oracle had launched XStream right after closing the deal with GoldenGate (a few hours back from now.), I thought that might be clever to publish those Java programs help people set up a XStream Inbound configuration and XStream Outbound configuration.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |