Re: [RavenDB] Trigger thread binding

[Kijana Woodard]

Hi. Welcome.

I didn't quite follow all that. 

Here's I would approach a problem like what I think I understood you have. 

1. Do nothing. See what the performance is like just being naive and calling Load on the doc. Raven has a bunch of caching and optimizations built in already.

2. Listen for changes with the Changes API and update an in memory cache. Now, all the other code just touches memory. We update state immediately, and only, upon change.

In terms of doing batches of reads/puts/deletes, the session is a unit of work and everything changed before SaveChanges succeeds or fails as a unit.

Is any of that helpful?

On Fri, May 24, 2013 at 1:26 PM, <chub...@gmail.com> wrote:

Hi,

 

i got in touch with ravendb (a wonderul piece of software!) a few weeks ago and now implemented a custom abstraction and advanced authentication and localization (multilanguage-support) plugin.

I'm already using several caching techniques to minimize the overhead of authorization on per document and type base.

 

for our case we need recursive group memberships with type and access level limitations.

as flattening out a complex tree with several recursions takes some document lookups and processing time i've also implemented a small session cache in my plugin.

 

overall i'm happy with the performance - even if we request several hundreds of items the extension doesn't result in lower performance (about 1-2% overall).

in order to ensure constant performance over special situations and for further extensions (there'll be some more complex ones which require shared information between several OnPut calls in one save command).

So, my question is as follows:

It would be quite useful if i could share information between several document reads / puts / deletes in the instance of my trigger (fast access to the members).

Using a ThreadLocal<> would be nice if each query would be completely executed in on thread.

Is this the case or are queries executed in parallel?

Is there a way to get information about the number of queried item of this request? (i would need to detect if the current item is the first / this is a new request and i have to purge my thread-local values :-)).

 

Parallel query execution would be useful in case of costly queries - but in our case it will be a web application and there "multithread" in nature of the client requests :-)

 

Kind regards,

Daniel

--
You received this message because you are subscribed to the Google Groups "ravendb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[chub...@gmail.com]

Hi Kijana,

 

thanks for you response.

The performance is quiet well - i would just like to be sure that some upcoming features will still be at high performance.

 

The changes API will also be some of the next features (also live projections which are very(!) nice) to use. 

 

I've yet another question. Is there a way to append custom headers per request?

We're using SharedOperationsHeaders for now which works well for static information like providing userIds for our authentication plugin.

Unfortunately we would need also some additional data to be injected on a per request base.

Is this possible?

 

Thanks so far!

[Kijana Woodard]

On a per request basis? Injected into what? Sounds like a standard ioc task.

[Oren Eini (Ayende Rahien)]

You have the JsonRequestFactory.CustomizeRequest event