Stephan van Hulst

Saloon Keeper
+ Follow
since Sep 20, 2010
Cologne, Germany
Cows and Likes
Cows
Total received
216
In last 30 days
4
Total given
191
Likes
Total received
2192
Received in last 30 days
45
Total given
258
Given in last 30 days
7
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan van Hulst

Yes, I wrote it without testing it, apologies. An alternative would be to declare 'a' as a field instead of a local variable.

Note that if you're going to try to reproduce the case where the code prints 0, the chance is extremely small, and may not even occur at all on some systems.
I don't have that book, so I'll need more context than what you're giving me.

Tim Holloway wrote:OK. You've confused me. Why should line 11 ever be executed before line 4?


Because lines 4 through 8 of the code I've written are exeucted by a different thread, and that thread may reach those lines later than the original thread reaches line 11.

Regardless of what order things do internally, their execution order as statements is not allowed to be altered.


Not true. Statements and parts of statements may be executed completely out of order, as long as the reordering doesn't affect the final results of the thread that executes them. No such guarantee is made for other threads.

Furthermore, there are limits even within statements. Otherwise the "short circuit" operators couldn't work reliably.


Of course there are limits, I'm not saying that instructions may be reordered willy-nilly. They MAY sometimes be reordered though, and that reordering MAY affect other threads if you don't use memory barriers correctly.

Note that even when the left hand side of a short-circuiting operator would cause the operator to shortcircuit, the right hand side MAY be executed regardless, due to branch prediction, but this is not visible at the Java level and is a whole different discussion anyway.

Tim Holloway wrote:When an object is being constructed, it's still in the hands of the JVM's object factory and so the regular application threads can't access it.


This is not true. You can get a reference to an uninitialized object if a thread other than the constructing thread can access the variable where the new object will be assigned to, as I demonstrated in my code above.
There is no difference. Neither is thread-safe.

Consider the following code:

This code may print either of the three following results:

  • 'a' doesn't reference an object
  • 1
  • 0

  • The first option is printed when line 4 executes before line 11. The second option is printed when line 11 executes before line 4 does.

    Now, you might ask how it's possible that this program can also print 0. The reason is that processors are allowed to reorder instructions to make execution more efficient. In theory, it's possible that the thread that executes line 11 assigns the new object reference to the a variable before it initializes the i field in the constructor. The thread that executes the if-statement on line 4 then sees that a is not null, and then calls a.getI(), which will return 0 if it finishes running before the constructor does.

    There's absolutely no difference between constructors and setters here. There's only a difference if you make i final. Besides making it so that the field can't be assigned a value more than once, it has the additional effect that other threads can not access the field before the constructor has finished running. If you make i final, the A class becomes thread-safe and the value 0 will never be printed.
    You already know the IDs of the seats. The seats aren't created when the user reserves them, they're already there. The user picks a seat (or is assigned one) and when a reservation is made, you could add a reservation entry that refers to a seat. You can add constraints to the database so that no two reservations for the same viewing may refer to the same seat. The simplest way to do this is by giving the reservation a compound unique key that consists of the viewing ID and the seat ID. When two reservations are made concurrently for the same seat, one of the two updates will cause an error, and make the entire transaction fail. You don't need a separate query to first check if the seat was already reserved.

    Even if you wanted to perform multiple queries in a single transaction, and two transactions occur concurrently, you can control to what extent the transactions can interfere with each other by setting the transaction isolation level.
    I use wildcard imports for common standard API packages.

    If I'm importing from uncommon packages or from libraries, I use normal imports. I always use normal imports for static imports. The reason is that if someone looks at my source code without using an IDE (such as when they're browsing GitHub), they should be able to find the package that a class or method is in by looking at the list of imports. To avoid cluttering the import list, I expect people to know what classes are from the common standard API packages.

    I consider common packages to be those from the following modules:

  • java.base
  • java.desktop
  • java.logging
  • java.se
  • java.xml
  • 2 days ago
    The only reason I can think of wanting to encrypt the file before sending it over a secure protocol, is when you only want the recipient to act as a data store, and don't want them to be able to read your files. You then only decrypt the file after retrieving it again at a later stage.

    As Matt pointed out, encrypting when the sender sends and decrypting when the receiver receives is the job of the secure protocol. Encrypting it twice makes no sense.

    And welcome to CodeRanch!
    You seem to be asking a lot of questions about singletons lately. Why are you using singletons? Why is it so important to you that you limit the instantiation of a class?

    Anyway, the purpose of the readResolve() method is to replace the deserialized object with one that you actually want to use in your application. The reasons for this can be many.

    A good example is when the data on disk looks very differently from the data in memory. You would then have one class that represents the data in memory, and one class that represents the data on disk. When you serialize an object, the serialization mechanism will call its writeReplace() method, where you can replace the object with an instance of the class that represents the data on disk. That object then gets serialized through the usual means. Later when you deserialize the object, the readResolve() method is called, where you can replace the object with an instance of the class as it appears in memory.

    There is no default implementation for these classes. They don't normally exist. It's just that the serialization mechanism checks for their existence using reflection, and if they DO exist, only then are they called.
    2 days ago
    Hah, unless you're willing to come up to Cologne, no thanks. Let us know when you managed to sort it all out.

    Gerard Ramon Monte wrote:A tiny detail is that i don't really want to store the people names, so could i use the table Hunter this way?
    ID - Role
    1 - EK
    2 - ED
    3 - RP
    4 - MS

    And then, in participation asign 1 to 4 depending of the vocation?


    Sure, but don't use abbreviations. Instead, create a table Role where you can give roles a name, and then let the Hunter table refer to a Role with a roleId column.

    So storing all the data this way, will allow me to keep showing the information in my table i shown you before? I supose i will have to do some SQL queries to get the information i want.


    Yes, or you can create views of your tables. They are like tables, except their values are calculated by performing queries on real tables.

    **The ¿? fields are things I don't know if I would have to add, or I can just calculate it and then show it in the application table using SQL queries.


    Correct, you can remove People and Profit and calculate them in a View.

    Then the participation table, will have (in the case we are 3 people in party), 3 rows refering to that hunt

    HuntIDHunterIDWasteTransfer
    11(EK)100150
    12(ED)300350
    13(RP)50100


    Instead of Waste, call it Expenses. Transfer is redundant, because it can be calculated, you only need to keep track if the participant has been paid yet. Unless payments to a participant can be made in multiple transactions for a single hunt, but you haven't explained that case yet.

    Then, to show this information in the application table, I can do SQL queries to get almost all the data, exept the things in ¿? wich I could just calculate at the moment.


    Yes. Here are some T-SQL queries I made so you can create views based on the tables I showed in the attachment above:

    Yes, it's clear to me, thanks for the explanation.

    Normalization is the process of eliminating all data that can be calculated from other data. In the diagram you've shown, Balance, Profit and Paid are redundant, because they can be calculated from Loot, Wastes and Transfers. TOTAL_Waste is also redundant. Instead of adding these properties to your tables as columns, you can create functions or views that calculate these properties for you.

    As Ron pointed out, the Respawn_Per_Hunt table is unnecessary. A hunt is performed in a single location, so you can have a direct reference to the Respawns table from the Hunts table.

    To get rid of the fixed columns in Wastes and Transfers, you will want to create a table for participants.

    I attached an example of a database design.