RavenDB Triggers + Rhino ESB

[racielrod]

I need to keep certain documents in sync with the reporting db, so any
change in Raven should be transferred to the equivalent reporting
entity on SQLServer.
I was thinking on using a one way bus on the triggers to send messages
to a consumer on the other end which will enact the changes in the SQL
server...
Does this sounds ok?
Has anybody done this before?

I would have to put the message configuration on web.config on the web
folder (I'm hosting Raven on IIS).
I would have to move certain binaries (Rhino's binaries, iocs, etc.. )
to the Raven bin folder...

Is there any better way to do this? The good thing about this approach
is that I can reflect the changes in real time, even when the
modifications are done in the Raven Studio...

Regards,
Raciel

[Alex]

Hi

I have also been looking at this kind of operation
actually, the best place for this could be using the replication from
ravenDB, hijacking the call and passing the message to your bus

god knows how that can be done, but you could perhaps even avoid
queuing your own messages, if RavenDB does eventual replication.

If someone could confirm , that would be great

Alex

[racielrod]

Hi Alex,

I created the triggers and they were failing -couldn't get useful logs
about what was going on- I'm working on the unit tests for the
consumer part, and I found several problems there I'm working on; some
of those should be causing the problems I see (I took the trigger to
the server w/o much testing, I was anxious).
Once I have the consumer part done and tested, I will move it again to
the server and I will keep you posted.

I prefer to have a new bundle to do this, rather than modifying the
replication; I want to be able to update the replication bundle w/o
having to introduce my messaging logic every time.

Also I have Audits (a custom version of versioning bundle),
replication and now this sync in place, so I want to play safe.

Thanks,
Raciel

[racielrod]

Is creating the oneway bus expensive? I'm creating it in the scope of
each delete and put triggers, not sure if there is a better place for
this?
Any help will be appreciated.

Thanks,
Raciel

[racielrod]

Ok,

This is working, so far. However I'm not sure on the bus creation and
the cost associated with it.
Daniel suggested here : http://groups.google.com/group/ravendb/browse_thread/thread/a758e82fbca84bfc
(or asked for a best practice advise) using an asynch task to perform
the heavy stuff, which I tend to agree with.

On the other hand, I need to send the message to the bus IF the action
is successfully performed on RavenDB, meaning I don't want to send a
delete message if the document deletion was rolled back. Same for a
put.
That being said, I think I can use the following approaches:

OnPut + Synchronous message delivery on the same transaction.
OnAfterCommit + Asynchronous message delivery, since I have the
warranty that the document was successfully written.

On the delete side I have no options but stick with OnDelete, since I
_do_ need information from the document to be included on the message.

Does this sounds reasonable?

[Oren Eini (Ayende Rahien)]

Note that you have the AfterCommit stuff specifically for those sort of reasons.

[Oren Eini (Ayende Rahien)]

OnPut makes very little sense, you might be successful in publishing the message, then fail the transaction

[racielrod]

I agree, however I have no options for the DeleteTrigger, the key
itself is not enough information on my case where I need a subset of
the document to identify it on the reporting db.
I could create a key that contains that, but it is not an option
now... I need to be able to handle old docs too.

Thanks!
Raciel




On Feb 17, 6:03 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>

wrote:
> OnPut makes very little sense, you might be successful in publishing the
> message, then fail the transaction
>
> On Sat, Feb 18, 2012 at 1:03 AM, Oren Eini (Ayende Rahien) <
>
>
>
>
>
>
>
> aye...@ayende.com> wrote:
> > Note that you have the AfterCommit stuff specifically for those sort of
> > reasons.
>

> > On Sat, Feb 18, 2012 at 12:42 AM, racielrod <raciel.rodrig...@gmail.com>wrote:
>
> >> Ok,
>
> >> This is working, so far. However I'm not sure on the bus creation and
> >> the cost associated with it.
> >> Daniel suggested here :

> >>http://groups.google.com/group/ravendb/browse_thread/thread/a758e82fb...

[Oren Eini (Ayende Rahien)]

A ThreadLocal is what you want, then.

[racielrod]

Should I store the document in the ThreadLocal in the OnDelete and use
it later in the OnAfterCommit where I have the certainty the
transaction succeeded?
Just double checking, I haven't used this concept before.

Thanks,
Raciel

On Feb 17, 7:01 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> A ThreadLocal is what you want, then.
>

[Oren Eini (Ayende Rahien)]

Raciel,

Yes, but store just the additional info you need.

Actually, you have the CurrentOperationContext that is already available.

Note that a transaction may have more than one document participating in it.

[racielrod]

Working like a charm :)

On Feb 18, 3:32 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> Raciel,
> Yes, but store just the additional info you need.
> Actually, you have the CurrentOperationContext that is already available.
> Note that a transaction may have more than one document participating in it.
>