Timestamp myth

In oracle, the column date_visited with Date type, in UI java code its type is java.util.Date. while saving to DB (in EJB entity bean), its type is java.sql.Timestamp. The weird thing happened is that after I saved the record the database and then queried it right away, I can't get the record back even it has been saving in DB.

   
   private static final String GET_SERVICE_LOCATION_QUERY = 
      "select * from service_location where service_recommendation_id=? " +
      "and location_id=? and date_visited=?";
 
   connection = DataSourceAccessUtil.getDataSource().getConnection();
   statement = connection.prepareStatement(GET_SERVICE_LOCATION_QUERY);
   statement.setLong(1, serviceRmdId);
   statement.setLong(2, locationId);
   SimpleDateFormat format = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");   
   statement.setTimestamp(3, new Timestamp(dateVisited));
   resultSet = statement.executeQuery();

The reason is in the precision. According to Oracle doc, "The DATE datatype stores point-in-time values (dates and times) in a table. The DATE datatype stores the year (including the century), the month, the day, the hours, the minutes, and the seconds (after midnight)." And java.sql.Timestamp captures time in *nano* level, a fraction of second (0-999,999,999). So the comparsion cannot be equal. I have to change to use to_char to make it work.

   
   private static final String GET_SERVICE_LOCATION_QUERY = 
      "select * from service_location where service_recommendation_id=? " + 
      "and location_id=? and to_char(date_visited, 'DD-MM-YYYY HH24:MI:SS')=?";
 
   connection = DataSourceAccessUtil.getDataSource().getConnection();
   statement = connection.prepareStatement(GET_SERVICE_LOCATION_QUERY);
   statement.setLong(1, serviceRmdId);
   statement.setLong(2, locationId);
   SimpleDateFormat format = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");   
   statement.setString(3, format.format(dateVisited));
   resultSet = statement.executeQuery();

Tag or untagged?

Fundamentally, there are only two different Ethernet switch port types: access or trunk.

An access switchport can only participate in the VLAN to which it has been assigned and data is not tagged.

A trunk switchport can participate in multiple VLANs but in order to do so expects the data to be 'tagged' so the switch will know where the data is ultimately expected to go. The switch then reads the VLAN ID tagged data and then knows to which ports it should be talking or where it should be going.

VLANs are typically used to provide logical separation for different network segments or subnets but it is important to realize that just because a switch supports layer-2 tagging (802.1q VLAN tagging) does not mean that it provides routing between them, which is a layer-3 function.

A trunk switchport would be employed if, for instance, your router supported trunking/tagging. Instead of simply being on VLAN 13, port 1 could be configured on the switch as a trunk port and both VLAN 13 and VLAN 459 would be set as tagged. Data from both networks could traverse the same physical wire back to your router but would not be aware of one another. Guests would still be isolated on VLAN 459 while the office was safe and sound on VLAN 13. Trunk switchports are typically employed in virtualization, where one network interface is expected to support systems on multiple VLAN IDs or network segments.

Tagged and untagged describe how a frame on a VLAN is transmitted from a port. The frame can be tagged in which case it will contains an 802.1q VLAN Tag Control information field, or not tagged. Untagged doesn't mean "not on a VLAN". In a VLAN-aware network, every packet is forwarded on a VLAN. In a VLAN-aware network frames need not contain a tag identifying the VLAN they are travelling on. Switches can use other mechanisms, such as policy to decide that.

VLAN is completely on wire side, wireless doesn't have this concept.

Design Pattern walkthrough

1. Proxy Pattern
- Proxy controls and manages access to the real subject.
- Same interface, so proxy can be substituted anywhere the subject can be used

• Remote proxy: act as local represtative (RMI)
• Virtual proxy: expensive to create, lazy initialization (Hibernate)
• Transaction proxy: wire transactional support (Spring)
• Security: protect

2. Command Pattern
- Encapsulate method invocation: store them, pass them around and invoke them when you need them
- It decouples the requester of an action from the oject that actually performs the action

• Order a meal: order slip
• Job queue: ControllerUpCmd, ApAddCmd
• Device import: commands passed around and executed in context (e.g., session establish, error handling), acts like closure, function pointer. It is like Template method pattern, but instead of subclassing, the method is passed as command objects here

3.Strategy Pattern
- Defines a family algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it
- Encapsulates the behaviour, take what varies and "encapsulate" it so it won't affect the rest of your code

4.Observer Pattern
- Defines a one-to-many dependency between objects so that when one object (subject) changes state, all of its dependents (observers) are notified and updated automatically
- Subjects and observers are *loosely* coupled
- A key part in the familiar Model View Controller (MVC) pattern

 

Convention over Configuration (CoC)

Maven, Grail are examples of applying CoC. So do many modern framework. CoC essentially means a developer only needs to specify unconvertional aspects of the application. Only when the desired behavior "deviates" from the implemented convention is explict configuraiton required.