Hello,
does the resolution of HSEARCH-209 imply we can get rid of the
private static final ThreadLocal> contexts = ...
in SearchFactoryImpl?
I never fully understood the need of that, I thought because we could
have several Search listeners
registered, but if we could delete
FullTextIndexCollect
Yes what you formalized is exactly what I meant; there's an additional point
in the
"piggyback" strategy, which is to actually use some volatile read (or any
other memorybarrier)
which you couldn't avoid anyway, to avoid the cost of reading a volatile.
No need to make it excessively complex of cour
Hibernate Search cannot guarantee that threads using the SearchFActory
have been started after the thread initializing the SearchFactory
(especially Containers can do stupid things).
So you need to do someting like that:
SF.init() {
...
myvolatile++; //write
}
and upon access to the Sear
Thanks for your blog Pavitar;
I would like to add some clarification about the "piggyback" just to
confirm:
there is no such concept as "THE shared memory" in the JMM, shared memory is
about memory shared between some threads, not necessarily all.
the "piggyback" trick works basing on this: after T
Hi Emmanuel,
Piggybacking on Synchronization is documented by Brian Goetz in Java
Concurrency In Practice section 16.1.4
Basically what it means is one can piggyback on visiblity properties of
existing synchronization(or volatile write).And other variables which are
not guarded by any such synchr
Doh I need System.Threading.Thread.MemoryBarrier() but in Java :(
--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com
| http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)
On Jul 4, 2008, at 16:26, Emmanuel Bernard wrote:
Hey,
Can you tell me more about the piggyback synchronization. I could not
find any decent knowledge online.
how far reading a volatile guarantee that all "local" values of the
thread we are reading from will be pushed to the shared memory?
For example, could reading a volatile value after HSe
Hi Pavitar Singh,
I thank you very much about your explanations but actually I opened the
issue myself
because I have read the same specs and am aware of that.
in H.Search (and several other hibernate code) there's this quite common
pattern for starting
"replaceable" objects (something like user-w
