Hello Rickard
and thanks for quite emptying replies. :) Unfortunately, I don't have the
DDD-book (yet). Maybe that thing needs to be fixed soon.
> <snip>
> So while you may think of the association as bidirectional, it may not
> be that in your actual model.
Hmm, well, I don't have THAT much experience from software modeling (starting
my MSc thesis this summer), so that might be very likely the case.
> Then there's another more practical side to it. If your WorldZone keeps
> a ManyAssociation to the objects it contains, then anytime an object is
> added or removed there will be contention and use of that
> ManyAssociation. If you have a multi-user system, I would guess that not
> much is going to go in or out of those zones, because you will have
> ConcurrentModificationExceptions pretty much all the time due to
> multiple concurrent usecases trying to change the ManyAssociation. You
> also severely limit your ability to scale the system since with a
> bidirectional association you HAVE to change both sides within the same
> transaction. In practice this means that you have to put them on the
> same server, or else you will have 2PC transactions going on, which
> won't scale. Are you sure you want to do this?
To be honest, I haven't even thought about those aspects yet. This is just a
(currently) little project of my own, barely few weeks old. I was hoping I
would get into those issues after some amount of iteration rounds, after the
core API would stabilize even a little. :) You're quite right on both issues
though.
> All of this makes it bad to have bidirectional associations. Fortunately
> there's a very simple solution to it which will give you simple code and
> a scalable system: keep the Association from WorldObject to WorldZone,
> and then implement the reverse as a Query.
Ahhh, I think I had something similar - asking the same thing from
RepositoryService. But that felt utterly clumsy. Queries are one of those
things I haven't explored in Qi4j yet - burning with desire now. :)
><snip>
> And that's it. This is very scalable, because there's no contention on
> anything: to have a task enter the inbox I just set the Owner to the
> Inbox. Any number of threads can therefore "add" tasks to the same inbox
> simultaneously, and I'll never get concurrency problems. Also, I don't
> have to have the owner and task on the same box, since all I need from
> the owner is the identity. The Inbox does not even have to know that
> Tasks are referring to it this way! This also ensures that the result is
> read-only, as there is NO way for the user to modify these results. It
> also deals with massive amounts of tasks better, since the query has
> startresult/maxresult settings for paging, and I'm guessing you will
> need this too in your situation.
>
> This answers how to deal with bidirectional associations.
>
Well, that sure was simple and effective. Thanks again, this feels like going
right way - no hacks, just straightward implementation.
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces.
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
