0

I guess JAXB calls the zero-arg constructor and then starts filling the non volatile fields and adds stuff to the lists.

In my own code: Immediately after doing this (the unmarshalling) the generated beans get deported to some worker threads over some add method, but not through the constructor or any other way that would trigger the memory model to flush and refetch the data to and from shared area.

Is this safe? Or does JAXB do some magic trick behind the scenes? I can't think of any way in the java programming language that could enforce everything being visible for all threads. Does the user of JAXB generated beans have to worry about fields maybe not being visibly set in a concurrent setup?

Edit: Why are there so many downvotes? Nobody was yet able to explain how JAXB ensures this seemingly impossible task.

Franz Kafka
  • 10,623
  • 20
  • 93
  • 149
  • 3
    "... but not through the constructor or any other way that would trigger the memory model to flush and refetch the data to and from shared area": How do you know that? This is just baseless speculation. – user207421 Mar 26 '12 at 00:08
  • 1
    Because I throw them into a thread in my code. Why would this be speculation? – Franz Kafka Mar 26 '12 at 08:16
  • Beacuse you throw *what* into a thread in your code? What is your question? You've raised a storm of speculation without presenting any evidence. FYI JAXB doesn't have any magical powers; it just constructs objects and calls getters and setters on them. – user207421 Mar 26 '12 at 09:32
  • @EJP seriously what is wrong with you? If you don't know the answer then don't post anything. And if you do know the answer then answer or feel uppity and keep it to yourself. Your unproductive misinterpreting of my question doens't help anybody. "you throw what into a thread in your code?" Answer: My code takes the beans filled by JAXB and throws them into a thread, how can that be so hard to understand? – Franz Kafka Mar 27 '12 at 20:42

1 Answers1

3

I won't bother to investigate the various "facts" in your question, I'll just paraphrase:

"Without references it ain't true!"

That said, anyone dealing with threads in Java these days will have to actually try to avoid establishing happens-before and happens-after relationships inadvertently. Any use of a volatile variable, a synchronized block, a Lock object or an atomic variable is bound to establish such a relationship. That immediately pulls in blocking queues, synchronized hash maps and a whole lot of other bits and pieces.

How are you so certain that the JAXB implementation actually manages to do the wrong thing?

That said, while objects obtained from JAXB are about as safe as any Java object once JAXB is done with them, the marshalling/unmarshalling methods themselves are not thread-safe. I believe that you do not have to worry unless:

  • Your threads share JAXB handler objects.

  • You are passing objects between your threads without synchronization: A decidedly unhealthy practice, regardless of where those objects came from...

EDIT:

Now that you have edited your question we can provide a more concrete answer:

JAXB-generated objects are as thread-safe as any other Java object, which is not at all. A direct constructor call offers no thread-safety on its own either. Without an established happens-before relationship, the JVM is free to return partially initialized objects at the time when new is called.

There are ways, namely via the use of final fields and immutable objects, to avoid this pitfall, but it is quite hard to get right, especially with JAXB, and it does not actually solve the issue of propagating the correct object reference so that all threads are looking at the same object.

Bottom line: it is up to you to move data among your threads safely, via the use of proper synchronization methods. Do not assume anything about the underlying implementation, except for what is clearly documented. Even then, it's better to play it safe and code defensively - it usually results in more clear interactions between the threads anyway. If at a later stage a profiler indicates a performance issue, then you should start thinking about fine-tuning your synchronization code.

Community
  • 1
  • 1
thkala
  • 84,049
  • 23
  • 157
  • 201
  • 1
    "Without references it ain't true!" It are not facts in my question. It is a question, waiting for an answer with facts. I don't know how JAXB handles this problem, that's why I am asking. It is a question not an answer. – Franz Kafka Mar 26 '12 at 08:22