Praveen Balaji

Vladimir Ozerov wrote:This is almost exactly what Embeddables are used for.

Not sure Embeddables are a solution, or like I said, I haven't figured it out yet. To quote from http://en.wikibooks.org/wiki/Java_Persistence/Embeddables:

In an application object model some objects are considered independent, and others are considered dependent parts of other objects. In UML a relationship to a dependent object is consider an aggregate or composite association. In a relational database this kind of relationship could be modeled in two ways, the dependent object could have its own table, or its data could be embedded in the independent objects table.

In JPA a relationship where the target object's data is embedded in the source object's table is considered an embedded relationship, and the target object is considered an Embeddable object. Embeddable objects have different requirements and restrictions than Entity objects and are defined by the @Embeddable annotation or <embeddable> element.

The way I understand this is, an Embeddable should have corresponding columns in a Database. In my case, the StudentDetails is merely a containing structure which holds data that would otherwise have been in the Student class.

Here's a simplified example of what I want to achieve:

I have 3 tables:

STUDENT { STUDENT_ID, NAME } HOBBY { STUDENT_REF, HOBBY } AWARD { STUDENT_REF, AWARDS }

1. STUDENT_REF colums have a foreign key referring to STUDENT_ID column.
2. There is a One-To-Many relationship between STUDENT and HOBBY/AWARD.

The standard way to model this in Java classes is:

@Entity class Student { int id; String name; @One-To-Many(...) Set<Hobby> hobbies; @One-To-Many(...) Set<Award> award; } @Entity class Hobby { ... } @Entity class Award { ... }

However, I want to introduce another containing class - StudentDetails - which does not have a mapping to any table and model it thus:

@Entity class Student { int id; String name; StudentDetails details; } class StudentDetails { @One-To-Many(...) Set<Hobby> hobbies; @One-To-Many(...) Set<Award> award; } @Entity class Hobby { Student student; ... } @Entity class Award { Student student; ... }


Note that Hobby and Award classes have a reference back to Student and not to StudentDetails.

How can I achieve this? Should I be using embedded objects? I haven't (yet) figured out how. Any hints will be appreciated and devoured.

Thanks in advance
Praveen

Thanks a lot guys for the input and links.

Originally posted by Rahul Bhattacharjee:
To my best of knowledge it has got nothing to do with performance.

Just curious to know that what made you think that it has something to do with performance.

I USUALLY prefer early aborts - specially when I'm validating function input. But someone mentioned it has performance implications. Googling didn't help much, but there may be a better search string I should be using.

Originally posted by praveen balaji:


As I mentioned above, the question is about performance.

Just for the record, there are several stylistic reasons for and against the use of "guard code" (Case 1). However, I'm interested in the performance implications.

Someone mentioned it has something to do with how Java allocates the function stack. I was looking for details.

Originally posted by Rahul Bhattacharjee:
Would you like modify a function with 10 exits/returns ,
knowing the fact that there are no JUnits for unit testing that piece ?

As I mentioned above, the question is about performance.

Just for the record, there are several stylistic reasons for and against the use of "guard code" (Case 1). However, I'm interested in the performance implications.
[ May 29, 2007: Message edited by: praveen balaji ]

Originally posted by Amit A. Patil:
Case 2 is always good from maintenance and support point.
When some other developer is looking at your code there makes it easier for hiom if there is a single return in the method

I should have been clearer there. I wanted to know from a performance POV. I modified the question.

Originally posted by Rahul Bhattacharjee:
I will go with Case II.I always prefer single return point for methods.

Someone mentioned that. Any reason why?

From a performance POV, is it better to return at just one place from a function rather than several places? Someone mentioned something to do with JVM allocations on the function stack.

Example:

Case 1:

{ if(obj == null) return null; return obj.bar; }

Case 2:
{ Object o = null; if(obj != null) o = obj.bar; return o; }

Is Case 2 better than Case 1?
[ May 29, 2007: Message edited by: praveen balaji ]

The ouput is like that because the JVM has been written to do that But I'm sure that's not what you intend to ask.

Can you explain what you understood and what the confusion is? The code just displays basic java thread behaviour. So, if you can explain which part of the output is confusing you, I will be able to help you with an explanation.



PS: If you are new to threads, you may want to read an online tutorial. Apart from a lesson on Threads, this will give you a good understanding of Thread.sleep() which, I guess, is creating confusion in this case. Try Sun Trail on Threading and Concurrency.

Difficult to explain this on a forum, but I'll try.

The BEST way to figure how the execution happens is by naming the threads and debugging through the code. You'll see multiple threads being created and figure out which steps can be executing parallely.

Remember that with paralelly executing threads, it's often difficult to predict the order of execution. There are some synchronization constructs, however, that can assure a "happens-before" relationship between instructions. You should look up the JSR-133.

Having said that, here is an attempt to answer your question. I have broken up the code in the main method.

public class JoinTest { static Thread createThread(final int i ,final Thread t1) { Thread t2 = new Thread(){ public void run() { System.out.println(i+1); try { t1.join(); } catch(InterruptedException e){} System.out.println(i+2); }}; System.out.println(i+3); t2.start(); System.out.println(i+4); return t2; } public static void main(String[] args) { Thread thread1 = Thread.currentThread(); Thread thread2 = createThread(20, thread1); createThread(10, thread2); } } /* 1. Remember that in createThread(int, Thread), t2 does not actually start executing till t2.start() is called 2. Remember that t1.join() waits for t1 to die. 3. On the call to createThread(20, thread1), the following happens a) t2 is created b) i+3 = 23 is printed c) t2 is started d) i+4 = 24 is printed 4. On the call to createThread(10, thread2), the following happens a) t2 is created b) i+3 = 13 is printed c) t2 is started d) i+4 = 14 is printed 5. On the call to createThread(20, thread1), i+1 = 21 can be printed anywhere after 3(c) before 7(b) 6. On the call to createThread(10, thread2), i+1 = 11 can be printed anywhere after 4(c) before 8(b) 7. Main thread dies: a) t2 in createThread(20, thread1) is interrupted b) i+2 = 22 is printed 8. thread2 dies a) t2 in createThread(10, thread2) is interrupted b) i+2 = 12 is printed. */

I'm sure it's confusing. But that's the way with threads. As one of the senior programmers at my previous company said: "Threads are like snakes. Dont use them if you dont have to".




PS: If it interests you: the more I think about it, the more I seem to believe that the world is single-threaded and procedural. It's like a see-saw. One end goes up and the other goes down. If you look at it separately, they are two events happening parallely.
The world is probably single threaded: think about parallel universes - the see-saw of the universe.

[ November 27, 2006: Message edited by: praveen balaji ]
[ November 27, 2006: Message edited by: praveen balaji ]

You can geta list of all running threads: List Of All Running Threads

I am not sure how you can figure the threads created by a particular code block. I was thinking about stack trace but stack trace is per thread and not across threads. So, it's not possible to know where it was spawned.

If your threads are named (or you could induce code to name them at the point they are created), you could probably iterate through the list of threads to check. But I am not sure you want to/can do that.

If you explain why you need to do this, we may be able to offer an alternative.

Not sure I got the question. Can you explain what you mean when you say you want to get the number of threads ... "by reading the java file"?

Do you intend to say you have a java class that spawns several threads and you want to see how many threads have been spawned by that particular class?

Short answer: It's possible. It's called Thread Starvation.

You may want to google for

1. Thread Starvation
2. Thread Busy Wait

I believe you are exploring threads (considering you posted 3 questions). Might be a good idea to invest in a book. I dont know which one, but someone should be able to point you to a good book.

I always find Sun Trails a nice place to start reading about any java features/libraries. You get a broad idea of what is offered and what you should look (google) for.
[ November 24, 2006: Message edited by: praveen balaji ]

Distinguish between code blocks and threads of execution. Multiple threads of execution could be executing the same code blocks.

CurrentThread referes to the thread that is executing that code block and not to all threads that are running in the JVM at that time.

Example:
Thread-1 and Thread-2 are simultaneously executing the below code path:

{
System.out.println(Thread.currentThread());
}


They both end up executing the System.out.println(). For Thread-1's execution path, CurrentThread is Thread-1. Similarly for Thread-2.

I hope I understood your question right.