text:
A Textbook of Community Medicine/History of Community Medicine

Community Medicine is a new branch of medicine. It is often considered synonymous with Preventive and Social Medicine(PSM), Public Health, and Community Health. All these share common ground, i.e., prevention of disease and promotion of health. In short, Community Medicine provides comprehensive health services ranging from preventive, promotive, curative to rehabilitative services. The importance of the speciality of Community Medicine has been very well recognised and emphasized repeatedly from grass root to international levels, not only in health sector but in other related sectors too. The scope of medicine has expanded during the last few decades to include not only health problems of individuals, but those of communities as well. If we want to achieve Health For All, Community Medicine will definitely be the key factor during the next millennium.

Evolution and Development
A branch of medicine that is concerned with the health of the members of a community, municipality, or region. The emphasis in community medicine is on the early diagnosis of disease, the recognition of environmental and occupational hazards to good health, and the prevention of disease in the community The industrial revolution of the 18th century while bringing affluence also brought new problems - slums, accumulation of refuse and human excreta, overcrowding and a variety of social problems. Frequent outbreaks of cholera added to the woes Chadwick’s report on ‘The Sanitary Conditions of Labouring Population (1842)’ focussed the attention of the people and Government on the urgent need to improve public health. Filth and garbage were recognised as man’s greatest enemies and it lead to great sanitary awakening bringing Public Health Act of 1848 in England, in acceptance of the principle that the state is responsible for the health of the people. The act was made more comprehensive in 1875 when Public Health Act 1875 was enacted. The public health movement in USA followed closely the English pattern. The organised professional body, American Public Health Association was formed in 1872.

Public Health is defined as the process of mobilising local, state, national and international resources to solve the major health problems affecting communities and to achieve Health For All by 2000 AD.

While Public Health made rapid strides in the western world, its progress has been slow in the developing countries where the main health problems continue to be those faced by the western world 100 years ago. The establishment of the World Health Organisation (WHO) providing a Health Charter for all people provided a great help to the public health movement in these countries.

Many different disciplines contributed to the growth of Public Health; physicians diagnosed diseases; sanitary engineers built water and sewerage systems; epidemiologists traced the sources of disease outbreaks and their modes of transmission; vital statisticians provided quantitative measures of births and deaths; lawyers wrote sanitary codes and regulations; public health nurses provided care and advice to the sick in their home; sanitary inspectors visited factories and markets to enforce compliance with public health ordinances; and administrators tried to organise everyone within the limits of the health departments budgets. Public Health thus involved Economics, Sociology, Psychology, Law, Statistics, and Engineering as well as biological and clinical sciences. Soon another important and emerging branch of medicine i.e., Microbiology became an integral part of Public Health. Public Health during the 19th Century was around sanitary regulations and the same underwent changes.

Community Medicine developed as a branch of medicine distinct from Public Health. By definition, Community medicine is applied to ‘healthy’ people, customarily by actions affecting large numbers or populations. Its primary objective is prevention of disease and promotion of health. The development of laboratory methods for the early detection of disease was a further advance. Community Medicine has been defined as that speciality which deals with populations, and comprises those doctors who try to measure the needs of the population, both sick and well, who plan and administer services to meet those needs, and those who are engaged in research and teaching in the field.

Decades old concept of health care approach has experienced a dramatic change. Today health is not merely an absence of disease; it is related to quality of life instead. Health is considered a means of productivity. Thus health development is essential to socio-economic development as a whole. Since health is an integral part of development, all sectors of society have an effect on health. Scope of medicine has extended from individual to community. Study of health and disease in population is replacing study of disease in man. Germ theory of disease gave place to newer concepts - multi-factorial causation. Social and behavioural aspects of the disease have been accorded a new priority. Contemporary medicine is no longer solely an art and science for the diagnosis and treatment of diseases. It is also the science for the prevention of disease and promotion of health. Today technical sophistication of modern medicine is not an answer to everyday common ailments of the vast poor in the country. Appropriate technology and cheaper interventions like Oral Rehydration Solution (ORS), immunisation, etc., are increasingly being applied as life saving measures and for disease prevention in community health care. Physicians’ role is no longer confined to diagnosing and treating those who come to the clinic. He is also responsible for those who need his service but can not come to the clinic. Health of the people is not only the concern of health care providers. It is the responsibility of the community also to identify and solve their own health problems through their active participation.

All these changes in concept and ideas of health and health care system are embodied in community health care. The spate of new ideas and concepts, for example, increasing importance given to social justice and equity, recognition of crucial role of community participation called for the new approaches to make medicine in the service of humanity more effective.

In 1978, the UN's Alma-Ata Declaration of Health for All by 2000 specified that Primary Health Care approaches are the means of achieving their goal of Health For All by 2000 AD. The Primary Health Care approach stressed that “essential health care should be made universally accessible to individuals and acceptable to them, through their full participation and at a cost the community and the country can afford”.


text:
XQuery/XQuery IDE

In progress

The eXist Database stores binary files as well as XML files. Binary files include the XQuery scripts themselves. This allows XQuery scripts to manipulate the XQuery scripts themselves - viewing, searching, analyzing, modifying and creating scripts, all the operations required of a development environment.

Viewing the XQuery script
The eXist util module includes functions to read binary documents and convert to text. Here they are used to view a script. In this public interface, a configuration file is used to control access to those scripts.

The script checks that a requested script name is present in the list of public scripts before retrieving the script.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: XQuery/XQuery IDE


text:
A Textbook of Community Medicine/History of Medicine

All human societies have medical beliefs that provide explanations for, and responses to birth, death, and disease. Throughout the world, illness has often been attributed to witchcraft, demons, averse astral influence, or the will of the gods, ideas that retain some power, with faith healing and shrines still common, although the rise of scientific medicine in the past two centuries has altered or replaced many historic health practices.

Ancient Egyptian Medicine
The Ancient Egyptians, like the Ancient Greeks and Romans, have provided modern historians with a great deal of knowledge and evidence about their attitude towards medicine and the medical knowledge that they had. This evidence has come from the numerous papyrus found in archaeological searches.

Like prehistoric man, some of the beliefs of the Egyptians were based on myths and legend. However, their knowledge was also based on an increasing knowledge of the human anatomy and plain common sense.

In Ancient Egypt, the treatment of illnesses was no longer carried out only by magicians and medicine men.Archaeological digs have also found evidence of men titled physicians.

Physicians lived even earlier in Ancient Egypt. Imphotep was the physician to King Zozer and lived in about 2600 BC. Imphotep was considered so important that he was, after his death, was worshipped as a god of healing.

Almost all of our knowledge about Ancient Egyptian medical knowledge comes from the discoveries of papyrus documents. The very dry atmosphere in Egypt has meant that many of these documents have been very well preserved despite their age. Numerous papyrus documents have come from the era 1900 BC to 1500 BC. It is from these documents that we know that the Ancient Egyptians still believed that the supernatural caused some disease.

When there was no obvious reason for an illness, many Ancient Egypt doctors and priests believed that disease was caused by spiritual beings. When no-one could explain why someone had a disease, spells and magical potions were used to drive out the spirits.The Ancient Egyptians also had a god who would frighten away evil spirits – Bes.

Despite this use of remedies that come from a lack of knowledge, the Ancient Egyptians also developed their knowledge as a result of education. Ancient papyrus inform us that the Ancient Egyptians were discovering things about how the human body worked and they knew that the heart, pulse rates, blood and air were important to the workings of the human body. A heart that beat feebly told doctors that the patient had problems.The document actually gives names to organs such as the spleen, the heart, the anus, the lungs etc., so they must have known that these exist. One papyrus, the Edwin Smith Papyrus, has a detailed description of the brain in it so this organ was also well researched by the standards of the time. It is probable that this knowledge came as a result of the practice the Ancient Egyptians had of embalming dead bodies.


text:
User:Mogaio

Islam Ahmed Hassan

Gender: Male

Relationship Status: Single

Birthday: March 7, 1989

Hometown: Alexandria, Egypt

Religious Views: Muslim

Contact Info

Email: mogaio@gmail.com

Google Talk: 	mogaio

Windows Live: 	mogaio

Skype: 	mogaio

Yahoo: 	mogaio

Current Town: 	Alexandria, Egypt

Website: 	http://alexandermind.blogspot.com

Personal Info

Interests: Linux / Java / C++ / Business / Economy / Stock Markets / Parapsychology / NLP / Some Sport.

Favorite Music:

Local Music, Classical

Favorite Song

Hasbi Rabbi-> Sami Yusuf

kan-nefsi---> Wama

Tla3elbadr 3lyna> Mshary Bn Rashed Ela3fasy

B3d El nights---> AmrDiab

Favorite Album

My Ummah

Mozart In Egypt

Current Favorite Artists / Bands

Loai / AmrDiab / Wama / Dalida / Beethoven Music / Mozart Music / Tchaikovsky Music

Favorite TV Shows:

AmrKaled Pro / Ibrahim Elfyqe Pro.

Favorite Books: 	 The Holy Quran / Anis Masour's Books / El3qad's Books

Links

 * Wikimania 2008/Alexandria.
 * Wikimedia Egypt.

title: User:Mogaio


text:
Talk:Physics Study Guide/Logs

It's misleading to say logs are base 10. Logs can be any base. You should say that "these examples use the base 10 log but other bases can be used, especially e, which is called the natural log" and give some examples with base subscripts.

title: Talk:Physics Study Guide/Logs


text:
User talk:PicoVerse

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.

I saw the page at x86 Assembly/Machine Language Conversion, and I agree that the XOR conversion example does not look correct. The W and D bits appear to be swapped, in addition to the errors you pointed out. I don't have time this week to research the topic and fix it myself. I may have time early next week. Any changes or additions that you want to make are welcome, feel free to ask if you have questions or if you want me to double-check your work. --Whiteknight (Page) (Talk) 12:43, 10 October 2007 (UTC)

 * WhiteKnight is correct, a lot of that page was wrong. I could see that right away, and I had the iAPX86 manual available, so I pulled that to check facts and corrected it to match reality. Hope I did OK... Chazz (talk) 03:40, 13 October 2007 (UTC)

title: User talk:PicoVerse


text:
Java Persistence/Relationships

=Relationships= A relationship is a reference from one object to another. In Java, relationships are defined through object references (pointers) from a source object to the target object. Technically, in Java there is no difference between a relationship to another object and a "relationship" to a data attribute such as a  or   (primitives are different), as both are pointers; however, logically and for the sake of persistence, data attributes are considered part of the object, and references to other persistent objects are considered relationships.

In a relational database relationships are defined through foreign keys. The source row contains the primary key of the target row to define the relationship (and sometimes the inverse). A query must be performed to read the target objects of the relationship using the foreign key and primary key information.

In Java, if a relationship is to a collection of other objects, a  or array type is used in Java to hold the contents of the relationship. In a relational database, collection relations are either defined by the target objects having a foreign key back to the source object's primary key, or by having an intermediate join table to store the relationship (both objects' primary keys).

All relationships in Java and JPA are unidirectional, in that if a source object references a target object there is no guarantee that the target object also has a relationship to the source object. This is different than a relational database, in which relationships are defined through foreign keys and querying such that the inverse query always exists.

JPA Relationship Types

 * OneToOne - A unique reference from one object to another, inverse of a.
 * ManyToOne - A reference from one object to another, inverse of a.
 * OneToMany - A  or   of objects, inverse of a.
 * ManyToMany - A  or   of objects, inverse of a.
 * Embedded - A reference to a object that shares the same table of the parent.
 * ElementCollection - JPA 2.0, a  or   of   or   objects, stored in a separate table.

This covers the majority of types of relationships that exist in most object models. Each type of relationship also covers multiple different implementations, such as OneToMany allowing either a join table, or foreign key in the target, and collection mappings also allow  types and   types. There are also other possible complex relationship types, see Advanced Relationships.

Lazy Fetching
The cost of retrieving and building an object's relationships far exceeds the cost of selecting the object. This is especially true for relationships such as  or   such that, if any employee were selected, it would trigger the loading of every employee through the relationship hierarchy. Obviously this is a bad thing, and yet having relationships in objects is very desirable.

The solution to this issue is lazy fetching (lazy loading). Lazy fetching allows the fetching of a relationship to be deferred until it is accessed. This is important not only to avoid the database access, but also to avoid the cost of building the objects if they are not needed.

In JPA lazy fetching can be set on any relationship using the  attribute. The  can be set to either   or   as defined in the FetchType enum. The default fetch type is  for all relationships except for   and , but in general it is a good idea to make every relationship. The  default for   and   is for implementation reasons (more difficult to implement), not because it is a good idea. Technically in JPA  is just a hint, and a JPA provider is not required to support it, however in reality all main JPA providers support it, and they would be pretty useless if they did not.

Magic
Lazy fetching normally involves some sort of magic in the JPA provider to transparently fault in the relationships as they are accessed. The typical magic for collection relationships is for the JPA provider to set the relationships to its own,  ,   or   implementation. When any (or most) method is accessed on this collection proxy, it loads the real collection and forwards the method. This is why JPA requires that all collection relationships use one of the collection interfaces (although some JPA providers support collection implementations too).

For  and   relationships the magic normally involves some sort of byte code manipulation of the entity class, or creation of a subclass. This allows the access to the field or get/set methods to be intercepted, and for the relationships to be first retrieved before allowing access to the value. Some JPA providers use different methods, such as wrapping the reference in a proxy object, although this can have issues with  values and primitive methods. To perform the byte code magic normally an agent or post-processor is required. Ensure that you correctly use your providers agent or post-processor otherwise lazy may not work. You may also notice additional variables when in a debugger, but in general debugging will still work as normal.

Basics
A  attribute can also be made , but this is normally a different mechanism than lazy relationships, and should normally be avoided unless the attribute is rarely accessed.

See Basic Attributes : Lazy Fetching.

Serialization, and Detaching
A major issue with lazy relationships is ensuring that the relationship is still available after the object has been detached or serialized. For most JPA providers, after serialization any lazy relationship that was not instantiated will be broken, and either throw an error when accessed or return null.

The naive solution is to make every relationship eager. Serialization suffers from the same issue as persistence, in that you can very easily serialize your entire database if you have no lazy relationships. So lazy relationships are just as necessary for serialization as they are for database access; however you need to ensure you have everything you will need after serialization instantiated upfront. You may mark only the relationships that you think you will need after serialization as ; this will work, but there are probably many cases when you do not need these relationships.

A second solution is to access any relationship you will need before returning the object for serialization. This has the advantage of being use case specific, so different use cases can instantiate different relationships. For collection relationships sending  is normally the best way to ensure a lazy relationship is instantiated. For  and   relationships, normally just accessing the relationship is enough (i.e.  ), although for some JPA providers that use proxies you may need to send the object a message (i.e. ).

A third solution is to use the JPQL  for the relationship when querying the objects. A join fetch will normally ensure the relationship has been instantiated. Some caution should be used with join fetch however, as it can become inefficient if used on collection relationships, especially multiple collection relationships as it requires an n^2 join on the database.

Some JPA providers may also provide certain query hints, or other such serialization options.

The same issue can occur without serialization, if a detached object is accessed after the end of the transaction. Some JPA providers allow lazy relationship access after the end of the transaction, or after the  has been closed, however some do not. If your JPA provider does not, then you may require that you ensure you have instantiated all the lazy relationships that you will need before ending the transaction.

Eager Join Fetching
One common misconception is that  means that the relationship should be join fetched, i.e. retrieved in the same SQL   statement as the source object. Some JPA providers do implement eager this way. However, just because something is desired to be loaded does not mean that it should be join fetched. Consider  - , a  's employee reference is made   as the employee is almost always loaded before the phone. However when loading the phone, you do not want to join the employee, the employee has already been read and is already in the cache or persistence context. Also just because you want two collection relationships loaded, does not mean you want them join fetch which would result in a very inefficient join that would return n^2 data.

Join fetching is something that JPA currently only provides through JPQL, which is normally the correct place for it, as each use case has different relationship requirements. Some JPA providers also provide a join fetch option at the mapping level to always join fetch a relationship, but this is normally not the same thing as. Join fetching is not normally the most efficient way to load a relationship anyway, normally batch reading a relationship is much more efficient when supported by your JPA provider.

See Join Fetching

See Batch Reading

Cascading
Relationship mappings have a  option that allows the relationship to be cascaded for common operations. is normally used to model dependent relationships, such as  ->. Cascading the  relationship allows for the  's ->  s to be persisted, removed, merged along with their parent.

The following operations can be cascaded, as defined in the CascadeType enum:
 * - Cascaded the  operation.  If   is called on the parent, and the child is also new, it will also be persisted.  If it is existing, nothing will occur, although calling   on an existing object will still cascade the persist operation to its dependents.  If you persist an object, and it is related to a new object, and the relationship does not cascade persist, then an exception will occur.  This may require that you first call persist on the related object before relating it to the parent.  General it may seem odd, or be desirable to always cascade the persist operation, if a new object is related to another object, then it should probably be persisted.  There is most likely not a major issue with always cascading persist on every relationship, although it may have an impact on performance.  Calling persist on a related object is not required, on commit any related object whose relationship is cascade persist will automatically be persisted.  The advantage of calling persist up front is that any generated ids will (unless using identity) be assigned, and the   event will be raised.
 * - Cascaded the  operation.  If   is called on the parent then the child will also be removed.  This should only be used for dependent relationships.  Note that only the   operation is cascaded, if you remove a dependent object from a   collection it will not be deleted, JPA requires that you explicitly call   on it.  Some JPA providers may support an option to have objects removed from dependent collection deleted, JPA 2.0 also defines an option for this.
 * - Cascaded the  operation.  If   is called on the parent, then the child will also be merged.  This should normally be used for dependent relationships.  Note that this only affects the cascading of the merge, the relationship reference itself will always be merged.  This can be a major issue if you use   variables to limit serialization, you may need to manually merge, or reset transient relationships in this case.  Some JPA providers provide additional   operations.
 * - Cascaded the  operation.  If   is called on the parent then the child will also be refreshed.  This should normally be used for dependent relationships.  Be careful enabling this for all relationships, as it could cause changes made to other objects to be reset.
 * - Cascaded all the above operations.

Orphan Removal (JPA 2.0)
Cascading of the  operation only occurs when the remove is called on the object. This is not normally what is desired on a dependent relationship. If the related objects cannot exist without the source, then it is normally desired to have them deleted when the source is deleted, but also have them deleted when they are no longer referenced from the source. JPA 1.0 did not provide an option for this, so when a dependent object was removed from the source relationship, it had to be explicitly removed from the. JPA 2.0 provides a  option on the OneToMany and OneToOne annotations and XML. Orphan removal will ensure that any object no longer referenced from the relationship is deleted from the database.

Target Entity
Relationship mappings have a  attribute that allows the reference class (target) of the relationship to be specified. This is normally not required to be set as it is defaulted from the field type, get method return type, or collection's generic type.

This can also be used if your field uses a public interface type, for example field is interface, but the mapping needs to be to implementation class. Another usage is if your field is a superclass type, but you want to map the relationship to a subclass.

Collections
Collection mappings include OneToMany, ManyToMany, and in JPA 2.0 ElementCollection. JPA requires that the type of the collection field or get/set methods be one of the Java collection interfaces,,  ,  , or.

Collection Implementations
Your field should not be of a collection implementation type, such as. Some JPA providers may support using collection implementations, many support  collection relationships to use the implementation class. You can set any implementation as the instance value of the collection, but when reading an object from the database, if it is  the JPA provider will normally put in a special   collection.

Duplicates
A  in Java supports duplicate entries, and a   does not. In the database, duplicates are generally not supported. Technically it could be possible if a  is used, but JPA does not require duplicates to be supported, and most providers do not.

If you require duplicate support, you may need to create an object that represents and maps to the join table. This object would still require a unique, such as a. See Mapping a Join Table with Additional Columns.

Ordering
JPA allows the collection values to be ordered by the database when retrieved. This is done through the annotation or   XML element.

The value of the  is a JPQL   string. This can be an attribute name followed by  or   for ascending or descending ordering. You could also use a path or nested attribute, or a "," for multiple attributes. If no  value is given it is assumed to be the   of the target object.

The  value must be a mapped attribute of the target object. If you want to have an ordered  you need to add an index attribute to your target object and an index column to its table. You will also have to ensure you set the index values. JPA 2.0 will have extended support for an ordered  using an.

Note that using an  does not ensure the collection is ordered in memory. You are responsible for adding to the collection in the correct order. Java does define a  interface and   collection implementation that does maintain an order. JPA does not specifically support, but some JPA providers may allow you to use a   or   for your collection type, and maintain the correct ordering. By default these require your target object to implement the  interface, or set a. You can also use the  method to sort a   when required. One option to sort in memory is to use property access and in your set and add methods call.

Order Column (JPA 2.0)
JPA 2.0 adds support for an. An  can be used to define an order   on any collection mapping. It is defined through the annotation or   XML element.

The  is maintained by the mapping and should not be an attribute of the target object. The table for the  depends on the mapping. For a  mapping it will be in the target object's table. For a  mapping or a   using a   it will be in the join table. For an  mapping it will be in the target table.

Example of a collection order column database
EMPLOYEE (table)

EMPLOYEE_PHONE (table)

PHONE(table)

Object corruption, one side of the relationship is not updated after updating the other side
A common problem with bi-directional relationships is the application updates one side of the relationship, but the other side does not get updated, and becomes out of sync. In JPA, as in Java in general, it is the responsibility of the application or the object model to maintain relationships. If your application adds to one side of a relationship, then it must add to the other side.

This is commonly resolved through  or   methods in the object model that handle both sides of the relationships, so the application code does not need to worry about it. There are two ways to go about this: you can either add the relationship maintenance code to only one side of the relationship, and only use the setter from that side (such as making the other side protected), or add it to both sides and ensure you avoid an infinite loop.

For example:

The code is similar for bi-directional  and   relationships.

Some expect the JPA provider to have magic that automatically maintains relationships. This was actually part of the EJB CMP 2 specification. However the issue is if the objects are detached or serialized to another VM, or new objects are related before being managed, or the object model is used outside the scope of JPA, then the magic is gone, and the application is left figuring things out, so in general it may be better to add the code to the object model. However some JPA providers do have support for automatically maintaining relationships.

In some cases it is undesirable to instantiate a large collection when adding a child object. One solution is to not map the bi-directional relationship, and instead query for it as required. Also some JPA providers optimize their lazy collection objects to handle this case, so you can still add to the collection without instantiating it.

Poor performance, excessive queries
This most common issue leading to poor performance is the usage of  relationships. This requires the related objects to be read when the source objects are read. So for example reading the president of the company with    will cause every   in the company to be read. The solution is to always make all relationships. By default  and   are   but   and   are not, so make sure you configure them to be. See, Lazy Fetching. Sometimes you have  configured but it does not work, see Lazy is not working.

Another common problems is the n+1 issue. For example consider that you read all  objects then access their. Since each  is accessed separately this will cause n+1 queries, which can be a major performance problem. This can be solved through Join Fetching and Batch Reading.

Lazy is not working
Lazy  and   relationships typically require some form of weaving or byte-code generation. Normally when running in JSE an  option is required to allow the byte-code weaving, so ensure you have the agent configured correctly. Some JPA providers perform dynamic subclass generation, so do not require an agent.

Example agent java -javaagent:eclipselink.jar ...

Some JPA providers also provide static weaving instead, or in addition to dynamic weaving. For static weaving some preprocessor must be run on your JPA classes.

When running in JEE lazy should normally work, as the class loader hook is required by the EJB specification. However some JEE providers may not support this, so static weaving may be required.

Also ensure that you are not accessing the relationship when you shouldn't be. For example if you use property access, and in your set method access the related lazy value, this will cause it to be loaded. Either remove the set method side-effects, or use field access.

Broken relationships after serialization
If your relationship is marked as  then if it has not been instantiated before the object is serialized, then it may not get serialized. This may cause an error, or return  if it is accessed after deserialization.

See, Serialization, and Detaching

Dependent object removed from OneToMany collection is not deleted
When you remove an object from a collection, if you also want the object deleted from the database you must call  on the object. In JPA 1.0 even if your relationship is, you still must call  , only the remove of the parent object is cascaded, not removal from the collection.

JPA 2.0 will provide an option for having removes from the collection trigger deletion. Some JPA providers support an option for this in JPA 1.0.

See, Cascading

My relationship target is an interface
If your relationship field's type is a public interface of your class, and only has a single implementer, then this is simple to solve, you just need to set a  on your mapping. See, Target Entity.

If your interface has multiple implementers, then this is more complex. JPA does not directly support mapping interfaces. One solution is to convert the interface to an abstract class and use inheritance to map it. You could also keep the interface, create the abstract class and make sure each implementer extends it, and set the  to be the abstract class.

Another solution is to define virtual attributes using get/set methods for each possible implementer, and map these separately, and mark the interface get/set as. You could also not map the attribute, and instead query for it as required.

See, Variable and Heterogeneous Relationships

Some JPA providers have support for interfaces and variable relationships.

 * TopLink, EclipseLink : Support variable relationships through their  annotation and XML.  Mapping to and querying interfaces are also supported through their  's   API.

=Advanced=

JPA 2.0 Relationship Enhancements

 * ElementCollection - A  or   of   or   values.
 * Map Columns - A  or   or   that has a ,   or   key not part of the target object.
 * Order Columns - A  or   or   can now have a   that defines the order of the collection when a   is used.
 * Unidirectional OneToMany - A  no longer requires the   inverse relationship to be defined.

Other Types of Relationships

 * Variable OneToOne, ManyToOne - A reference to an interface or common unmapped inheritance class that has multiple distinct implementors.
 * Variable OneToMany, ManyToMany - A   or   of heterogeneous objects that share an interface or common unmapped inheritance class that has multiple distinct implementers.
 * Nested collection relationships, such as an array of arrays,  of  s, or   of  s, or other such combinations.
 * Object-Relational Data Type - Relationships stored in the database using,  ,  , or   types.
 * XML relationships - Relationships stored as XML documents.

Maps
Java defines the  interface to represent collections whose values are indexed on a key. There are several  implementations, the most common is , but also   and.

JPA allows a  to be used for any collection mapping including, ,   and. JPA requires that the  interface be used as the attribute type, although some JPA providers may also support using   implementations.

In JPA 1.0 the map key must be a mapped attribute of the collection values. The annotation or   XML element is used to define a map relationship. If the  is not specified it defaults to the target object's.

Map Key Columns (JPA 2.0)
JPA 2.0 allows for a  where the key is not part of the target object to be persisted. The  key can be any of the following:
 * A  value, stored in the target's table or join table.
 * An  object, stored in the target's table or join table.
 * A foreign key to another, stored in the target's table or join table.

Map columns can be used for any collection mapping including,,   and.

This allows for great flexibility and complexity in the number of different models that can be mapped. The type of mapping used is always determined by the value of the, not the key. So if the key is a  but the value is an   a   mapping is still used. But if the value is a  but the key is an   a   mapping is used.

This allows some very sophisticated database schemas to be mapped. Such as a three way join table, can be mapped using a  with a   for the third foreign key. For a  the key is always stored in the. For a  it is stored in the   if defined, otherwise it is stored in the target  's table, even though the target   does not map this column. For an  the key is stored in the element's table.

The annotation or   XML element is used to define a map relationship where the key is a   value, the  and  can also be used with this for   or   types. The annotation or   XML element is used to define a map relationship where the key is an   value, the  can also be used with this for composite foreign keys. The annotation or   XML element can be used when the key is an   or to specify the target class or type if generics are not used.

Example of a map key column relationship database
EMPLOYEE (table)

PHONE(table)

Example of a map key join column relationship database
EMPLOYEE (table)

PHONE(table)

PHONETYPE(table)

Example of a map key class embedded relationship database
EMPLOYEE (table)

EMPLOYEE_PHONE (table)

PHONE (table)

Join Fetching
Join fetching is a query optimization technique for reading multiple objects in a single database query. It involves joining the two object's tables in SQL and selecting both object's data. Join fetching is commonly used for  relationships, but also can be used for any relationship including   and.

Join fetching is one solution to the classic ORM n+1 performance problem. The issue is if you select n  objects, and access each of their addresses, in basic ORM (including JPA) you will get 1 database select for the   objects, and then n database selects, one for each   object. Join fetching solves this issue by only requiring one select, and selecting both the  and its.

JPA supports join fetching through JPQL using the  syntax.

Example of JPQL Join Fetch
This causes both the  and   data to be selected in a single query.

Outer Joins
Using the JPQL  syntax a normal   join is performed. This has the side effect of filtering any  from the result set that did not have an address. An  join in SQL is one that does not filter absent rows on the join, but instead joins a row of all   values. If your relationship allows  or an empty collection for collection relationships, then you can use an   join fetch, this is done in JPQL using the   syntax.

Note that  joins can be less efficient on some databases, so avoid using an   if it is not required.

Mapping Level Join Fetch and EAGER
JPA has no way to specify that a join fetch always be used for a relationship. Normally it is better to specify the join fetch at the query level, as some use cases may require the related objects, and other use cases may not. JPA does support an  option on mappings, but this means that the relationship will be loaded, not that it will be joined. It may be desirable to mark all relationships as  as everything is desired to be loaded, but join fetching everything in one huge select could result in a inefficient, overly complex, or invalid join on the database.

Some JPA providers do interpret  as join fetch, so this may work on some JPA providers. Some JPA providers support a separate option for always join fetching a relationship.

 * TopLink, EclipseLink : Support a  annotation and XML on a mapping to define that the relationship always be join fetched.

Nested Joins
JPA 1.0 does not allow nested join fetches in JPQL, although this may be supported by some JPA providers. You can join fetch multiple relationships, but not nested relationships.

Duplicate Data and Huge Joins
One issue with join fetching is that duplicate data can be returned. For example consider join fetching an 's phoneNumbers relationship. If each  has 3   objects in its phoneNumbers collection, the join will require to bring back n*3 rows. As there are 3 phone rows for each employee row, the employee row will be duplicated 3 times. So you are reading more data than if you have selected the objects in n+1 queries. Normally the fact that your executing fewer queries makes up for the fact that you may be reading duplicate data, but if you consider joining multiple collection relationships you can start to get back j*i duplicate data which can start to become an issue. Even with  relationships you can be selecting duplicate data. Consider join fetching an 's manager: if all or most employee's have the same manager, you will end up selecting this manager's data many times. In this case you would be better off not using join fetch, and allowing a single query for the manager.

If you start join fetching every relationship, you can start to get some pretty huge joins. This can sometimes be an issue for the database, especially with huge outer joins.

One alternative solution to join fetch that does not suffer from duplicate data is using Batch Fetching.

Batch Fetching
Batch fetching is a query optimization technique for reading multiple related objects in a finite set of database queries. It involves executing the query for the root objects as normal. But for the related objects the original query is joined with the query for the related objects, allowing all of the related objects to be read in a single database query. Batch fetching can be used for any type of relationship.

Batch fetching is one solution to the classic ORM n+1 performance problem. The issue is if you select n  objects, and access each of their addresses, in basic ORM (including JPA) you will get 1 database select for the   objects, and then n database selects, one for each   object. Batch fetching solves this issue by requiring one select for the  objects and one select for the   objects.

Batch fetching is more optimal for reading collection relationships and multiple relationships as it does not require selecting duplicate data as in join fetching.

JPA does not support batch reading, but some JPA providers do.

 * TopLink, EclipseLink : Support a  annotation and xml element and a   query hint to enable batch reading.  Three forms of batch fetching are supported, ,  , and.

See also,
 * Batch fetching - optimizing object graph loading

Filtering, Complex Joins
Normally a relationship is based on a foreign key in the database, but on occasion it is always based on other conditions. Such as  having many  s but also a single home phone, or one of his phones that has the   type, or a collection of "active" projects, or other such condition.

JPA does not support mapping these types of relationships, as it only supports mappings defined by foreign keys, not based on other columns, constant values, or functions. Some JPA providers may support this. Workarounds include, mapping the foreign key part of the relationship, then filtering the results in your get/set methods of your object. You could also query for the results, instead of defining a relationship.

 * TopLink, EclipseLink : Support filtering and complex relationships through several mechanisms. You can use a   to define a   on any mapping using the   criteria API.  This allows for any condition to be applied including constants, functions, or complex joins.  You can also use a   to define the SQL or define a   for the mapping's.

Variable and Heterogeneous Relationships
It is sometimes desirable to define a relationship where the type of the relationship can be one of several unrelated, heterogeneous values. This could either be a OneToOne, ManyToOne, OneToMany or ManyToMany relationship. The related values may share a common interface, or may share nothing in common other than subclassing. It is also possible to conceive of a relationship that could also be any  value, or even an.

In general JPA does not support variable, interface, or heterogeneous relationships. JPA does support relationships to inheritance classes, so the easiest workaround is normally to define a common superclass for the related values.

Another solution is to define virtual attributes using get/set methods for each possible implementer, and map these separately, and mark the heterogeneous get/set as. You could also not map the attribute, and instead query for it as required.

For heterogeneous  or   relationships one solution is to serialize the value to a binary field. You could also convert the value to a  representation that you can restore the value from, or store the value to two columns, one storing the   value and the other the class name or type.

Some JPA providers have support for interfaces, variable relationships, and/or heterogeneous relationships.

 * TopLink, EclipseLink : Support variable relationships through their  annotation and XML.  Mapping to and querying interfaces are also supported through their  's   API.

Nested Collections, Maps and Matrices
It is somewhat common in an object model to have complex collection relationships such as a  of  s (i.e. a matrix), or a   of  s, or a   of  s, and so on. Unfortunately these types of collections map very poorly to a relational database.

JPA does not support nested collection relationships, and normally it is best to change your object model to avoid them to make persistence and querying easier. One solution is to create an object that wraps the nested collection.

For example if an  had a   of  s keyed by a   project-type and the value a   or  s.  To map this a new   class could be created to store the project-type and a   to.

Example nested collection database
EMPLOYEE (table)

PROJECTTYPE (table)

PROJECTTYPE_PROJECT (table)

/Mapping

title: Java Persistence/Relationships


text:
Java Persistence/ManyToOne

=ManyToOne=

A  relationship in Java is where the source object has an attribute that references another object, the target object. I.e. the rather typical Java case that one object holds a reference to another object. A  relationship can be specified unidirectional. However, it is typical that the target object has the inverse relationship specified back to the source object. This would be a  relationship specification in the target object. All relationships in Java and JPA are unidirectional, in that if a source object references a target object there is no guarantee that the target object also has a relationship to the source object. This is different than a relational database, in which relationships are defined through foreign keys and querying such that the inverse query always exists.

In JPA a  relationship is specified through the   annotation or the   element. A  annotation is typically accompanied by a   annotation. The  annotation specifies how the relationship should be mapped to (expressed in) the database. The  defines the name of the foreign key column  in the source object that should be used to find (join) the target object.

If the reverse  relationship is specified in the target object, then the   annotation in the target object must contain a   attribute to define this inverse relation.

JPA also defines a  relationship, which is similar to a   relationship, except that the inverse relationship (if it were defined) is a   relationship. The main difference between a  and a   relationship in JPA is that a   always contains a foreign key from the source object's table to the target object's table, whereas a   relationship the foreign key may either be in the source object's table or the target object's table.

Example of a ManyToOne relationship database
EMPLOYEE (table)

PHONE (table)

Foreign key is also part of the primary key.

 * See Primary Keys through OneToOne Relationships.

Foreign key is also mapped as a basic.

 * If you use the same field in two different mappings, you typically require to make one of them read-only using.
 * See Target Foreign Keys, Primary Key Join Columns, Cascade Primary Keys.

Constraint error on insert.

 * This typically occurs because you have incorrectly mapped the foreign key in a  relationship.
 * See Target Foreign Keys, Primary Key Join Columns, Cascade Primary Keys.

 * It can also occur if your JPA provider does not support referential integrity, or does not resolve bi-directional constraints. In this case you may either need to remove the constraint, or use     to ensure the order your objects are written in.

Foreign key value is null

 * Ensure you set the value of the object's, if the   is part of a bi-directional   relationship, ensure you set the object's   when adding an object to the  , JPA does not maintain bi-directional relationships for you.
 * Also check that you defined the  correctly, ensure you did not set   or use a.

=Advanced=

Target Foreign Keys, Primary Key Join Columns, Cascade Primary Keys
In complex data models it may be required to use a target foreign key, or read-only  in mapping a   if the foreign key/  is shared with other   or   mappings.

See, Target Foreign Keys, Primary Key Join Columns, Cascade Primary Keys

/Mapping

title: Java Persistence/ManyToOne


text:
Java Persistence/ManyToMany

=ManyToMany=

A  relationship in Java is where the source object has an attribute that stores a collection of target objects and (if) those target objects had the inverse relationship back to the source object it would also be a   relationship. All relationships in Java and JPA are unidirectional, in that if a source object references a target object there is no guarantee that the target object also has a relationship to the source object. This is different than a relational database, in which relationships are defined through foreign keys and querying such that the inverse query always exists.

JPA also defines a  relationship, which is similar to a   relationship except that the inverse relationship (if it were defined) is a   relationship. The main difference between a  and a   relationship in JPA is that a   always makes use of a intermediate relational join table to store the relationship, where as a   can either use a join table, or a foreign key in target object's table referencing the source object table's primary key.

In JPA a  relationship is defined through the   annotation or the   element.

All  relationships require a. The  is defined using the   annotation and   XML element. The  defines a foreign key to the source object's primary key, and a foreign key to the target object's primary key. Normally the primary key of the  is the combination of both foreign keys.

Example of a ManyToMany relationship database
EMPLOYEE (table)

EMP_PROJ (table)

PROJECT (table)

Bi-directional Many to Many
Although a  relationship is always bi-directional on the database, the object model can choose if it will be mapped in both directions, and in which direction it will be mapped in. If you choose to map the relationship in both directions, then one direction must be defined as the owner and the other must use the  attribute to define its mapping. This also avoids having to duplicate the  information in both places.

If the  is not used, then the persistence provider will assume there are two independent relationships, and you will end up getting duplicate rows inserted into the join table. If you have a conceptual bi-directional relationship, but have two different join tables in the database, then you must not use the, as you need to maintain two independent tables.

As with all bi-directional relationships it is your object model's and application's responsibility to maintain the relationship in both direction. There is no magic in JPA, if you add or remove to one side of the collection, you must also add or remove from the other side, see object corruption. Technically the database will be updated correctly if you only add/remove from the owning side of the relationship, but then your object model will be out of synch, which can cause issues.

Object not in collection after refresh.

 * If you have a bi-directional  relationship, ensure that you add to both sides of the relationship.
 * See Object corruption.

Additional columns in join table.

 * See Mapping a Join Table with Additional Columns

Duplicate rows inserted into the join table.

 * If you have a bidirectional  relationship, you must use   on one side of the relationship, otherwise it will be assumed to be two different relationships and you will get duplicate rows inserted into the join table.

=Advanced=

Mapping a Join Table with Additional Columns
A frequent problem is that two classes have a  relationship, but the relational join table has additional data. For example if  has a   with   but the PROJ_EMP join table also has an   column. In this case the best solution is to create a class that models the join table. So a  class would be created. It would have a  to   and , and attributes for the additional data. and  would have a   to the. Some JPA providers also provide additional support for mapping to join tables with additional data.

Unfortunately mapping this type of model becomes more complicated in JPA because it requires a composite primary key. The association object's  is composed of the   and   ids. The JPA 1.0 spec does not allow an  to be used on a   so the association class must have two duplicate attributes to also store the ids, and use an , these duplicate attributes must be kept in synch with the   attributes. Some JPA providers may allow a  to be part of an , so this may be simpler with some JPA providers. To make your life simpler, I would recommend adding a generated  attribute to the association class. This will give the object a simpler  and not require duplicating the   and   ids.

This same pattern can be used no matter what the additional data in the join table is. Another usage is if you have a  relationship between two objects, with a third unrelated object or data representing the   key. The JPA spec requires that the  key be an attribute of the   value, so the association object pattern can be used to model the relationship.

If the additional data in the join table is only required on the database and not used in Java, such as auditing information, it may also be possible to use database triggers to automatically set the data.

Example join table association object database
EMPLOYEE (table)

PROJ_EMP (table)

PROJECT (table)

Example join table association object annotations
http://giannigar.wordpress.com/2009/09/04/mapping-a-many-to-many-join-table-with-extra-column-using-jpa/
 * If the given examples won't suit your expectations, try the solution indicated in this link:

/Mapping

title: Java Persistence/ManyToMany


text:
User talk:64.90.244.101

-- Herby talk thyme 14:35, 10 October 2007 (UTC)

title: User talk:64.90.244.101


text:
User talk:Sammate

-- Herby talk thyme 14:37, 10 October 2007 (UTC)

title: User talk:Sammate


text:
ICT for Disaster Management/Conclusion

It was essential that we look at disaster also management from the development angle. It is no longer either a one-off or stand-alone activity.Despite the fact that disaster preparedness has not been identified as one of the MDGs, it is apparent that proper mechanisms for disaster awareness and means of disaster recovery are essential to achieving the MDGs. In particular, the MDG targets such as integrating the principles of sustainable development into country policies and programmes, and reversing the loss of environmental resources can never be achieved without giving due emphasis to effective disaster management strategies.

The key priorities for the future, as illustrated by the UN/ISDR report ‘Living with Risk’(2004), can be extremely useful to help understand the prospects of ICT in disaster risk reduction.

First, as the report points out, there is a need for disaster and risk reduction to be an essential part of the broader concerns of sustainable development,and hence the need to make sure that risk assessments and vulnerability reduction measures are taken into account in different fields, such as environmental management, poverty reduction and financial management. Second, it is essential to note that current development practices do not necessarily reduce community vulnerability to disasters – indeed, ill-advised and misdirected development practices may actually increase disaster risks. A considerable challenge remains in raising awareness of this concern and to influence and enhance existing development projects, poverty reduction strategies and other programmes to systematically reduce disaster risk.

Third, political commitment by public and private policy makers and local community leaders, based on an understanding of risks and disaster reduction concepts, is fundamental to achieving change. Finally, even though national and local authorities bear the main responsibility for the safety of their people, it is the international community’s duty to advocate policies and actions in developing countries that pursue informed and well-designed disaster risk reduction strategies, and to ensure that their own programmes reduce disaster risks. The challenge is to determine the role of ICT in addressing these priorities. ICT is only a tool and it should not be treated as a panacea for all issues arising in disaster management.As is the case with any other tool, the effectiveness of ICT in reducing disaster risk depends on how it is used. The use of ICT for disaster management should not be a choice between this medium/ technology against that medium/technology. The very reason for the existence of so many channels is that none of them is suitable for every situation. One medium that might fit best under a certain set of circumstances might be of little use under another.Thus, what is required is not a competition between different media and technologies, but instead, using the best combination depending upon the circumstances. One obvious challenge facing the Asia-Pacific region is the low ICT penetration level in most of the region’s developing countries.According to the UNDP Human Development Report of 2005, in 2003, the tele-densities of Cambodia, Nepal and Bangladesh were 38, 18 and 15 per 1,000 people, respectively. The situation is the same for radio and television. The irony is that while a small selection of households might have all of these media, the majority does not have any of them. With such low penetration levels, it is extremely difficult to establish any effective ICT-based disaster warning system. For such communities, it is essential to think of other means (such as community radio or public address systems). Unless the levels of telephone, radio and television penetration can be reasonably increased, it is difficult to guarantee that such a community can be free from disaster risks, irrespective of the efficiency of the disaster monitoring systems. Another significant challenge to be recognized is the reluctance of some national governments to implement ICT-friendly policies. Many governments do not see investment in ICT or even building up ICT-enabling infrastructure as priorities. The result invariably will be that ICT and technology in general take a backseat to presumed priorities such as ensuring good governance practices, providing healthcare facilities and addressing gender barriers. The examples provided in this e-Primer make it obvious that as far as disaster management is concerned, there is no reason why ICT should take such a secondary role. ICTs, in this context, are not just commercial tools that are being used for the sole purpose of increasing profits in a business; they play a much larger role in protecting the well-being of the general population. It should therefore be the responsibility of all concerned stakeholders, from governments to donor organizations, to give the right priority to ICT development and adoption. Only that will ultimately guarantee disaster risk reduction for all.

title: ICT for Disaster Management/Conclusion


text:
ICT for Disaster Management/References

Acharya,Mahesh. 2005.‘Amateur Radio, A potential tool in emergency operations’, i4d Magazine,Volume 3, Number 1, January 2005, Centre for Science,Development and Media Studies,New Delhi, India. http://www.i4donline.net/jan05/amateur.asp ADPC.Tsunami Early Warning System (TEWS) website: http://www.adpc.net/general/adpc_TEWS.html AlertNet website: http://www.alertnet.org Clothier, Julie. 2005.‘Dutch trial SMS disaster alert system’, CNN.com. http://edition.cnn.com/2005/TECH/11/09/dutch.disaster.warning/index.html Convio website: http://www.convio.com Daily News, 2006.‘Disaster alarm system to be set up soon’, 26 January 2006, Associated Newspapers of Ceylon Ltd., Colombo, Sri Lanka. De Silva, Chamindra, undated. Sahana FOSS Disaster Management System. http://www.linux.lk/~chamindra/docs/Sahana-Case-Study.pdf DesInventar website: http://www.desinventar.org/desinventar.html Dunnette, Roxana. 2006. ’Radio and TV Broadcasting for Disaster Relief and Public Warning’, Pacific Telecommunications Council ’06 Proceedings. http://www.ptc06.org/program/public/proceedings/ Roxana%20Dunnette_paper_t151%20(formatted).pdf Gidley, Ruth. 2005.‘Covering conflicts and disasters: the media mandate’, Proceedings of the Asian Media Information and Communication Centre Annual Conference, Beijing, China, July 2005. Putnam, Laurie, 2002. ’By Choice or by Chance: How the Internet Is Used to Prepare for, Manage, and Share Information about Emergencies’, First Monday,Volume 7, Number 11 (November 2002). http://www.firstmonday.org/issues/issue7_11/putnam/index.html Sahana website: http://www.sahana.lk Samarajiva, Rohan,Malathy Knight-John, Peter S. Anderson and Ayesha Zainudeen. 2005. National Early Warning System: Sri Lanka – A Participatory Concept Paper for the Design of an Effective All-Hazard Public Warning System,Version 2.1, LIRNEasia, Sri Lanka. http://www.lirneasia.net/2005/03/national-early-warning-system Sarvodaya website: http://www.sarvodaya.org Subramanian,T. S. 2005.‘Their own warning systems’, Frontline,Volume 22, Issue 02, 15-28 January 2005. http://www.hinduonnet.com/fline/fl2202/stories/20050128006701600.htm

title: ICT for Disaster Management/References


text:
Cyber Guide to ODU Career Management/Get Up-to-Date/CAP Meeting

PHASED OUT - Use CAP Meeting instead

CAP Meeting
9:30 AM, every 2nd & 4th Wednesday - Champion Room

AGENDA 2/27
 * Virtual Meeting via Connect (link to be provided)
 * Employer Evaluation with Inquisite format - A little more tweaking. (pcp/alj)
 * Optimal Resume reviews due
 * Spring Career Fair Update (Randy)
 * Target Case Study Update (Randy)
 * Blogs (Laura)
 * FOCUS 2 (Heidi)

ACTION ITEMS
 * 2/13 - UC Brochure - 7 thing you should know about the CMC
 * 2/13 - Optimal Resume Demo Will King, Regional Sales Manager, 802-253-8338, willk@optimalresume.com will set up 30 day demo
 * 2/13 - "Outside" Internship Postings - contact those in your area to offer assistance
 * 2/13 - Holding Bin - Internships - Need to make sure schedules and college interns don't sit ther (Bev)
 * 2/13 - Program Evals discussed - Laura will modify and send out draft (Laura)
 * 2/13 - C3M Mass Email - submit one person from your College or area for mass emails (Laura)
 * Summer Project - Workshops not seminars
 * 11/14 - Part of Heidi and Penny Action Item**Pictures as Ned & Nadine (Head Holes - Andy)
 * 11/14 - Penny will work with Andy, Paul, and Christine A. to arrange these C3M Surveys. Penny will add item to agenda when survey results are available in preparation for next year's event.
 * 11/14 - Develop "refresher course" for new (1st semester) Coordinators in January. Blackboard site created 12/12

ACCOMPLISHMENTS 2/13 - All present (but Joe) Marketing Campaign:  Feb 18-Feb 28: Liaisons do preliminary marketing to targeted audiences within colleges using C3M and fliers. Invite to attend information table to find out how to win a $500 scholarship. Will need special flier to invite students to the information table. This flier is needed asap since it will only be used between Feb 18 and Feb 28. It would help if the flier had lots of Target logo and our logo also. This can be posted in buildings, passed out in classrooms, etc.  Information Table in Webb Lobby - Feb 28, 2008 Use "Are you on Target to Win?" with Team Entry deadline Mar 3, 2008 Pass out "Team Entry Form" and Case Synopsis Revise Team Entry Form to have Student Name, UIN, Major, Year in school  Competition Dates: Mar 7, 2008 Team Entry Forms are due in CMC, 2202 Webb Can we arrange for Ramonica to collect them and distribute to appropriate Liaisons?  Competition "Kick-Off" Target Visit March 18, 2008 Meet with Target Executives in Williamsburg Room? Student Team Q&A (Must have 2 team members present)  April 7, 2008, Noon, EXECUTIVE REPORT DEADLINE, turn in to CMC. Identify the name of someone to receive the reports in main CMC.  Apr 7-10, 2008: CMC staff review reports and choose top five team finalists. Do we meet together to review them?  April 11, 2008: Announce Finalists and schedule presentation time for Finalists' Presentations.How do we announce them?  April 25, Time and location?. Can we get the Williamsburg Room? Will Target spring for light refreshments? Beverages?  Do we know yet how the money will be distributed to the winners?
 * GEICO Internship target population Golden Key and 3.2 and above(Bev)
 * Target Case Study timeline finalized - Penny's synopsis:

1/23 - All present (but Joe) Make sure your Program Type is complete! VERIFIED COMPLETE Stats DEADLINE January 11! Talked about adding newsletters, scholarships 1/09 - All present, Alice Late 12/12 - All present Guest: Cynthia (OCR) 11/28 - Cancelled - No Agenda Items 11/14 - Started on time. Absent: Laura, Randy; Erin - LATE (Global Certificate Program)
 * Locate Leonda brochure Document (found)
 * Layout for Etiquette Dinner/Thundertix (Erin)
 * Annual Report Add newsletters, scholarships (Geico - Penny) (Warren - Alice)
 * Link to Professional Organizations/Participation List from intranet, begin intranet page (Laura) For ALL to update
 * Calendar (all deadlines internal and external - Use PowerPoint template)(Laura)
 * 1/09 and 1/23 - SIGN UP for your events in C3M - Employer participation runs through Joe
 * 1/09 - Prepare for the Fair - Don't be a Job Fair Dummie/Dress for Success being updated (Penny)
 * UC Strategic Plan progress report - Bullets complete: J:\Everyone\Strategic Plan\UC\UC Strategic Plan - PROGRESS
 * CPT Keys for events - work with Cyber Coaches to assure lock-up - invite cybercoach from calendar!
 * $5 cost for etiquette dinner through front desk, cancellations/deadline: Tues. 3/25 - Employers sign up through eR Career Fairs
 * Text Messages - Use as REMINDER function, need to know more about system to plan
 * Add eR Email filter to students in C3M (done)
 * ICAP Step by Step draft (Jen)
 * C3M Kiosk REQUEST (complete)
 * Satellite choices - (top) I am here for: 1) Scheduled Appointment 2) Walk-in (remove choice screen)
 * Main choices - (top) I am here for: 1) Cyber Career Center 2) Scheduled Appointment 3) On-Campus Interview 4) as is
 * Annual Report highlights/narrative via email to Laura - DEADLINE NOON 12/13
 * Jobs in eR MUST have a Job Type (Intern/Coop/Job) this is different that Job Classification- PLEASE take special care when activating! (Discussed in Senior Staff too)
 * Events Planning - Coop/Intern/Majors Fair (Bev)/Senior Scramble(Penny)/Etiquette (Erin)
 * Employer Participation Plan to run through Joe via C3M (Joe)
 * Experiential Education Agenda items will follow CAP meeting in the future (Bev)
 * Prepare for the Fair - Coop/Intern/Majors Career Fair Tips ready to go (Penny) Updated on web (Laura)
 * OCR Update: Randy provided a procedure.  We all agreed.
 * CAP evaluations/late papers - Deadlines to be determined at separate meeting (Bev)
 * CMC KnowledgeBuilder (Blackboard > My Professional Learning Reviewed Blackboard site for ongoing training(Laura)
 * Calendar reminder (Bev)
 * Series and Ned & Nadine Revamp ideas (Done)
 * Resume Reviews with Ned & Nadine (Done)
 * Revised Career Fair Tips (Penny) - Reviewed copy of new information. Heidi will work with Penny to revise links to Job Fair Dress Approriately. Penny will revise Tips for the Coop Intern Majors Fair.
 * Spring Schedule - On Williamsburg Schedule Spring Schedule has been updated. Spring Schedule still needs to be added to C3M.
 * UVA Bus Trip Recommendations (Penny)*Arrange to survey students who attended and those who did not attend. * Students and Cyber Center Resume Reviews - Bev/Erin. Cyber Center Handbook with samples/tips per college for resumes? Student instructed to bring critiqued resume with Cyber Center initials to the College Liaison or Coordinator. We may need to schedule another Resume Training session for the Coordinators.
 * Defense Intelligence Agency event (Bev/Penny) Agreed to have one person do the C3M search and email for all colleges based on the job specs.
 * Coordinator Evaluations - due Dec 1. Forms located in J:Forms/Coordinator/ eval forms.  Student worker forms are located in New Employee folder.

10/24- started at 9:30 am ABSENT: Andrea, NOT EARLY: Alice (here at 10), GUEST: Jennifer Gilliam, Target Case Studies
 * Assigned non-assigned seminars on C3M
 * Each college/area will handle one Advice & Slice (6) and collaborate on one Employer/Mentor Panel (3) per semester
 * Info Sessions - If not run through marketing, liaison puts on eR and C3M, email Laura/Heidi to put on web
 * Process for reporting missing equipment: 1) email staff to recover, 2) after 2 days report to Tom (for Police report)
 * Target Case Studies Program presentation (handouts)

10/10 LATE: Randy, Penny, Bev (Employer meeting) GUESTS: Jen (ICAP), Lisa (Give-Aways) 9/26 ABSENT: Penny LATE: Randy 8/29
 * Added Management Trainee Program CLASSIFICATION to eR (Laura)
 * Updated Data Entry Standards with Employer Caution List (Laura)
 * Requested CCC project - eR Email filter into C3M (Laura)
 * Added Employing International Students link to ISS on Employer Toolbox(Laura)
 * ICAP Update for Liaisons (Jen F)
 * CPT - Reviewed Data Entry Standards related to Work Authorization (Penny)
 * C3M Mass Emails - Reviewed need for targeted emails from C3M (Bev)
 * EARS process through C3M reviewed
 * Kiosk password will be changed reflecting new semester 9/27
 * On Campus Recruiting Info Session Scheduling, Coordination, Marketing Process
 * Cyber Coach Projects/Status updated on intranet dashboard (Heidi)
 * Distribute Williamsburg Troubleshooting (Laura)
 * Prepare for the Fair is now live (your input is welcome!)(Laura)
 * Updated Front Desk Protocol (Heidi/Ramonica)
 * Established Front Desk protocol for making appointments
 * Reviewed process for Success Story collection
 * Reviewed process for Marketing/Cyber Center Projects
 * Added C3M Topics: Advising & Course Related


text:
Java Persistence/Locking

=Locking=

Locking is perhaps the most ignored persistence consideration. Most applications tend to ignore thinking about concurrency issues during development, and then smush in a locking mechanism before going into production. Considering the large percentage of software projects that fail or are canceled, or never achieve a large user base, perhaps this is logical. However, locking and concurrency is a critical or at least a very important issue for most applications, so probably should be something considered earlier in the development cycle.

If the application will have concurrent writers to the same objects, then a locking strategy is critical so that data corruption can be prevented. There are two strategies for preventing concurrent modification of the same object/row; optimistic and pessimistic locking. Technically there is a third strategy, ostrich locking, or no locking, which means put your head in the sand and ignore the issue.

There are various ways to implement both optimistic and pessimistic locking. JPA has support for version optimistic locking, but some JPA providers support other methods of optimistic locking, as well as pessimistic locking.

Locking and concurrency can be a confusing thing to consider, and there are a lot of misconcepts out there. Correctly implementing locking in your application typically involves more than setting some JPA or database configuration option (although that is all many applications that think they are using locking do). Locking may also involve application level changes, and ensuring other applications accessing the database also do so correctly for the locking policy being used.

Optimistic Locking
Optimistic locking assumes that the data will not be modified between when you read the data until you write the data. This is the most common style of locking used and recommended in today's persistence solutions. The strategy involves checking that one or more values from the original object read are still the same when updating it. This verifies that the object has not changed by another user in between the read and the write.

JPA supports using an optimistic locking version field that gets updated on each update. The field can either be numeric or a timestamp value. A numeric value is recommended as a numeric value is more precise, portable, performant and easier to deal with than a timestamp.

The annotation or   element is used to define the optimistic lock version field. The annotation is defined on the version field or property for the object, similar to an  mapping. The object must contain an attribute to store the version field.

The object's version attribute is automatically updated by the JPA provider, and should not normally be modified by the application. The one exception is if the application reads the object in one transaction, sends the object to a client, and updates/merges the object in another transaction. In this case the application must ensure that the original object version is used, otherwise any changes in between the read and write will not be detected. The    API will always merge the version, so the application is only responsible for this if manually merging.

When a locking contention is detected an will be thrown. This could be wrapped inside a RollbackException, or other exceptions if using JTA, but it should be set as the  of the exception. The application can handle the exception, but should normally report the error to the user, and let them determine what to do.

Not sending version to client, only locking on the server

 * Probably the most common mistake in locking in general is locking the wrong section of code. This is true no matter what form of locking is used, whether it be optimistic or pessimistic.  The basic scenario is:
 * User requests some data, the server reads the data from the database and sends it to the user in their client (doesn't matter if the client is html, rmi, web service).
 * The user edits the data in the client.
 * The user submits the data back to the server.
 * The server begins a transaction, reads the object, merges the data and commits the transaction.
 * The issues is that the original data was read in step 1, but the lock was not obtained until step 4, so any changes made to the object in between steps 1 and 4 would not result in a conflict. This means there is little point to using any locking.

 * A key point is that when using database pessimistic locking or database transaction isolation, this will always be the case, the database locks will only occur in step 4, and any conflicts will not be detected. This is the main reason why using database locking does not scale to web applications, for the locking to be valid, the database transaction must be started at step 1 and not committed until step 4.  This means that a live database connection and transaction must be held open while waiting for the web client, as well as locks, since there is no guarantee that the web client will not sit on the data for hours, go to lunch, or disappear of the face of the earth, holding database resources and locking data for all other users can be very undesirable.

 * For optimistic locking the solution is relatively simple, the object's version must be sent to the client along with the data (or kept in the http session). When the user submits the data back, the original version must be merged into the object read from the database, to ensure that any changes made between step 1 and 4 will be detected.

Handling optimistic lock exceptions

 * Unfortunately programmers can frequently be too clever for their own good. The first issue that comes up when using optimistic locking is what to do when an   occurs.  The typical response of the friendly neighborhood super programmer, is to automatically handle the exception.  They will just create a new transaction, refresh the object to reset its version, and merge the data back into the object and re-commit it.  Presto problem solved, or is it?

 * This actually defeats the whole point of locking in the first place. If this is what you desire, you may as well use no locking.  Unfortunately, the   should rarely be automatically handled, and you really need to bother the user about the issue.  You should report the conflict to the user, and either say "your sorry but an edit conflict occurred and they are going to have to redo their work", or in the best case, refresh the object and present the user with the current data and the data that they submitted and help them merge the two if appropriate.

 * Some automated merge tools will compare the two conflicting versions of the data and if none of the individual fields conflict, then the data will just be automatically merged without the user's aid. This is what most software version control systems do.  Unfortunately the user is typically better able to decide when something is a conflict than the program, just because two versions of the .java file did not change the same line of code does not mean there was no conflict, the first user could have deleted a method that the other user added a method to reference, and several other possible issues that cause the typically nightly build to break every so often.

Paranoid Delusionment

 * Locking can prevent most concurrency issues, but be careful of going overboard in over analyzing to death every possible hypothetical occurrence. Sometimes in an concurrent application (or any software application) bad stuff can happen.  Users are pretty used to this by now, and I don't think anyone out there thinks computers are perfect.

 * A good example is a source code control system. Allowing users to overwrite each other changes is a bad thing; so most systems avoid this through versioning the source files.  If a user submits changes to a file that originated from a older version than the current version, the source code control system will raise a conflict and make the user merge the two files.  This is essentially optimistic locking.  But what if one user removes or renames a method in one file, then another user adds a new method or call in another file to that old method?  No source code control system that I know of will detect this issue, it is a conflict and will cause the build to break.  The solution to this is to start locking or checking the lock on every file in the system (or at least every possible related file).  Similar to using optimistic read locking on every possible related object, or pessimistically locking every possible related object.  This could be done, but would probably be very expensive, and more importantly would now raise possible conflicts every time a user checked in, so would be entirely useless.

 * So, in general be careful of being too paranoid, such that you sacrifice the usability of your system.

Other applications accessing same data

 * Any form of locking that is going to work requires that all applications accessing the same data follow the same rules. If you use optimistic locking in one application, but no locking in another accessing the same data, they will still conflict.  One fake solution is to configure an update trigger to always increment the version value (unless incremented in the update).  This will allow the new application to avoid overwriting the old application's changes, but the old application will still be able to overwrite the new application's changes.  This still may be better than no locking at all, and perhaps the old application will eventually go away.

 * One common misconception is that if you use pessimistic locking, instead of adding a version field, you will be ok. Again pessimistic locking requires that all applications accessing the same data use the same form of locking.  The old application can still read data (without locking), then update the data after the new application reads, locks, and updates the same data, overwriting its changes.

Isn't database transaction isolation all I need?

 * Possibly, but most likely not. Most databases default to read committed transaction isolation.  This means that you will never see uncommitted data, but this does not prevent concurrent transactions from overwriting the same data.

 * Transaction A reads row x.
 * Transaction B reads row x.
 * Transaction A writes row x.
 * Transaction B writes row x (and overwrites A's changes).
 * Both commit successfully.

 * This is the case with read committed, but with serializable this conflict would not occur. With serializable either Transaction B would lock on the select for B and wait (perhaps a long time) until Transaction A commits.  In some databases Transaction A may not wait, but would fail on commit.  However, even with serializable isolation the typical web application would still have a conflict.  This is because each server request operates in a different database transaction.  The web client reads the data in one transaction, then updates it in another transaction.  So optimistic locking is really the only viable locking option for the typical web application.  Even if the read and write occurs in the same transaction, serializable is normally not the solution because of concurrency implications and deadlock potential.

 * See Serializable Transaction Isolation

What happens if I merge an object that was deleted by another user?

 * What should happen is the merge should trigger an  because the object has a version that is not null and greater than 0, and the object does not exist.  But this is probably JPA provider specific, some may re-insert the object (this would occur without locking), or throw a different exception.

 * If you called  instead of merge, then the object would be re-inserted.

What if my table doesn't have a version column?

 * The best solution is probably just to add one. Field locking is another solution, as well as pessimistic locking in some cases.
 * See Field Locking

What about relationships?

 * See Cascaded Locking

Can I use a timestamp?

 * See Timestamp Locking

Do I need a version in each table for inheritance or multiple tables?

 * The short answer is no, only in the root table.
 * See Multiple Versions

Timestamp Locking
Timestamp version locking is supported by JPA and is configured the same as numeric version locking, except the attribute type will be a  or other date/time type. Be cautious in using timestamp locking as timestamps have different levels of precision in different databases, and some database do not store a timestamp's milliseconds, or do not store them precisely. In general timestamp locking is less efficient than numeric version locking, so numeric version locking is recommended.

Timestamp locking is frequently used if the table already has a last updated timestamp column, and is also a convenient way to auto update a last updated column. The timestamp version value can be more useful than a numeric version, as it includes the relevant information on when the object was last updated.

The timestamp value in timestamp version locking can either come from the database, or from Java (mid-tier). JPA does not allow this to be configured, however some JPA providers may provide this option. Using the database's current timestamp can be very expensive, as it requires a database call to the server.

Multiple Versions
An object can only have one version in JPA. Even if the object maps to multiple tables, only the primary table will have the version. If any fields in any of the tables changes, the version will be updated. If you desire multiple versions, you may need to map multiple version attributes in your object and manually maintain the duplicate versions, perhaps through events. Technically there is nothing preventing you from annotating multiple attributes with, and potentially some JPA providers may support this.

Cascaded Locking
Locking objects is different than locking rows in the database. An object can be more complex than a simple row; an object can span multiple tables, have inheritance, have relationships, and have dependent objects. So determining when an object has changed and needs to update its version can be more difficult than determining when a row has changed.

JPA does define that when any of the object's tables changes the version is updated. However it is less clear on relationships. If,  , or a foreign key relationship  changes, the version will be updated. But what about,  , and a target foreign key  ? For changes to these relationships the update to the version may depend on the JPA provider.

What about changes made to dependent objects? JPA does not have a cascade option for locking, and has no direct concept of dependent objects, so this is not an option. Some JPA providers may support this. One way to simulate this is to use write locking. JPA defines the EntityManager lock API. You can define a version only in your root parent objects, and when a child (or relationship) is changed, you can call the lock API with the parent to cause a  lock. This will cause the parent version to be updated. You may also be able to automate this through persistence events.

Usage of cascaded locking depends on your application. If in your application you consider one user updating one dependent part of an object, and another user updating another part of the object to be a locking contention, then this is what you want. If your application does not consider this to be a problem, then you do not want cascaded locking. One of the advantages of cascaded locking is you have fewer version fields to maintain, and only the update to the root object needs to check the version. This can make a difference in optimizations such as batch writing, as the dependent objects may not be able to be batched if they have their own version that must be checked.

 * TopLink / EclipseLink : Support cascaded locking through their  and   annotations and XML.

Field Locking
If you do not have a version field in your table, optimistic field locking is another solution. Field locking involves comparing certain fields in the object when updating. If those fields have changed, then the update will fail. JPA does not support field locking, but some JPA providers do support it.

Field locking can also be used when a finer level of locking is desired. For example if one user changes the object's name and another changes the objects address, you may desire for these updates to not conflict, and only desire optimistic lock errors when users change the same fields. You may also only be concerned about conflicts in changes to certain fields, and not desire lock errors from conflicts in the other fields.

Field locking can also be used on legacy schemas, where you cannot add a version column, or to integrate with other applications accessing the same data which are not using optimistic locking (note if the other applications are not also using field locking, you can only detect conflicts in one direction).

There are several types of field locking:
 * All fields compared in the update - This can lead to a very big where clause, but will detect any conflicts.
 * Selected fields compared in the update - This is useful if conflicts in only certain fields are desired.
 * Changed fields compared in the update - This is useful if only changes to the same fields are considered to be conflicts.

If your JPA provider does not support field locking, it is difficult to simulate, as it requires changes to the update SQL. Your JPA provider may allow overriding the update SQL, in which case,  or   field locking may be possible (if you have access to the original values), but   field locking is more difficult because the update must be dynamic. Another way to simulate field locking is to  you changes, then refresh the object using a separate   and connection and compare the current values with your original object.

When using field locking it is important to keep the original object that was read. If you read the object in one transaction and send it to a client, then update in another, you are not really locking. Any changes made between the read and write will not be detected. You must keep the original object read managed in an  for your locking to have any effect.

 * TopLink / EclipseLink : Support field locking through their  annotation and XML.

Read and Write Locking
It is sometimes desirable to lock something that you did not change. Normally this is done when making a change to one object, that is based on the state of another object, and you wish to ensure that the other object represents the current state of the database at the point of the commit. This is what serializable transaction isolation gives you, but optimistic read and write locking allow this requirement to be met declaratively and optimistically (and without deadlock, concurrency, and open transaction issues).

JPA supports read and write locks through the API. The argument can either be   or. A  lock will ensure that the state of the object does not change on commit. A  lock will ensure that this transaction conflicts with any other transaction changing or locking the object. Essentially the  lock checks the optimistic version field, and the   checks and increments it.

Example of Using the Lock API
Write locking can also be used to provide object-level locks. If you desire for a change to a dependent object to conflict with any change to the parent object, or any other of its dependent objects, this can be done through write locking. This can also be used to lock relationships, when you change a OneToMany or ManyToMany relationship you can also force the parent's version to be incremented.

No Locking a.k.a Ostrich Locking
Conceptually people may scoff and be alarmed at the thought of no locking, but it is probably the most common form of locking in use. Some call it Ostrich locking as the strategy is to stick your head in the sand and ignore the issue. Most prototypes or small applications frequently do not have the requirement or in most cases the need for locking, and handling what to do when a locking contention does occur is beyond the scope of the application, so best to just ignore the issue.

In general it is probably best in JPA to enable optimistic locking always, as it is fairly simple to do, at least in concept, but what does occur on a conflict without any form of locking? Essentially it is last in wins, so if two users edit the same object, at the same time, the last one to commit will have their changes reflected in the database. This is true, at least for users editing the same fields, but if two users edit different fields in the same object, it depends on the JPA implementation. Some JPA providers only update exactly the fields that were changed, where as other update all fields in the object. So in one case the first user's changes would be overridden, but in the second they would not.

Pessimistic Locking
Pessimistic locking means acquiring a lock on the object before you begin to edit the object, to ensure that no other users are editing the object. Pessimistic locking is typically implemented through using database row locks, such as through the  SQL syntax. The data is read and locked, the changes are made and the transaction is committed, releasing the locks.

JPA 1.0 did not support pessimistic locking, but some JPA 1.0 providers do. JPA 2.0 supports pessimistic locking. It is also possible to use JPA native SQL queries to issue  and use pessimistic locking. When using pessimistic locking you must ensure that the object is refreshed when it is locked, locking a potentially stale object is of no use. The SQL syntax for pessimistic locking is database specific, and different databases have different syntax and levels of support, so ensure your database properly supports your locking requirements.

 * EclipseLink (as of 1.2) : Supports JPA 2.0 pessimistic locking.
 * TopLink / EclipseLink : Support pessimistic locking through the  query hint.

The main issues with pessimistic locking is they use database resources, so require a database transaction and connection to be held open for the duration of the edit. This is typically not desirable for interactive web applications. Pessimistic locking can also have concurrency issues and cause deadlocks. The main advantages of pessimistic locking is that once the lock is obtained, it is fairly certain that the edit will be successful. This can be desirable in highly concurrent applications, where optimistic locking may cause too many optimistic locking errors.

There are other ways to implement pessimistic locking, it could be implemented at the application level, or through serializable transaction isolation.

Application level pessimistic locking can be implemented through adding a locked field to your object. Before an edit you must update the field to locked (and commit the change). Then you can edit the object, and set the locked field back to false. To avoid conflicts in acquiring the lock, you should also use optimistic locking, to ensure the lock field is not updated to true by another user at the same time.

JPA 2.0 Locking
JPA 2.0 adds support for pessimistic locking, as well as other locking options. A lock can be acquired using the API, or passing a   to an     or   operation, or setting the   of a   or.

The JPA 2.0 lock modes are defined in the LockModeType enum:
 * OPTIMISTIC (was READ in JPA 1.0) - The Entity will have its optimistic lock version checked on commit, to ensure no other transaction updated the object.
 * OPTIMISTIC_FORCE_INCREMENT (was WRITE in JPA 1.0) - The Entity will have its optimistic lock version incremented on commit, to ensure no other transaction updated (or READ locked) the object.
 * PESSIMISTIC_READ - The Entity is locked on the database, prevents any other transaction from acquiring a PESSIMISTIC_WRITE lock.
 * PESSIMISTIC_WRITE - The Entity is locked on the database, prevents any other transaction from acquiring a PESSIMISTIC_READ or PESSIMISTIC_WRITE lock.
 * PESSIMISTIC_FORCE_INCREMENT - The Entity is locked on the database, prevents any other transaction from acquiring a PESSIMISTIC_READ or PESSIMISTIC_WRITE lock, and the Entity will have its optimistic lock version incremented on commit. This is unusual as it does both an optimistic and pessimistic lock, normally an application would only use one locking model.
 * NONE - No lock is acquired, this is the default to any find, refresh or query operation.

JPA 2.0 also adds two new standard query hints. These can be passed to any,  , or  ,   or   operation.
 * "javax.persistence.lock.timeout" - Number of milliseconds to wait on the lock before giving up and throwing a.
 * "javax.persistence.lock.scope" - The valid scopes are defined in PessimisticLockScope, either NORMAL or EXTENDED. EXTENDED will also lock the object's owned join tables and element collection tables.

Serializable Transaction Isolation
Serializable transaction isolation guarantees that anything read in the transaction will not be updated by any other user. Through using serializable transaction isolation and ensuring the data being edited is read in the same transaction, you can achieve pessimistic locking. It is important to ensure the objects are refreshed from the database in the transaction, as editing cached or potentially stale data defeats the point of locking.

Serializable transaction isolation can typically be enabled on the database, some databases even have this as the default. It can also be set on the JDBC, or through native SQL, but this is database specific and different databases have different levels of support. The main issues with serializable transaction isolation are the same as using  (see above for the gory details), in addition everything read is locked, so you cannot decide to only lock certain objects at certain times, but lock everything all the time. This can be a major concurrency issue for transactions with common read-only data, and can lead to deadlocks.

How database implement serializable transaction isolation differs between databases. Some databases (such as Oracle) can perform serializable transaction isolation in more of an optimistic sense, than the typically pessimistic implementation. Instead of each transaction requiring locks on all the data as it is read, the row versions are not checked until the transaction is committed, if any of the data changed an exception is thrown and the transaction is not allowed to commit.

/Mapping

title: Java Persistence/Locking


text:
User talk:221.128.190.63

Thanks for experimenting with Wikibooks. Your test worked, and has now been removed. Please use Sandbox for any other tests you want to do, since testing material in modules will normally be removed quickly. Please see the welcome page if you would like to learn more about contributing to our project. Thanks. -- Urbane   (Talk)   (Contributions)  16:51, 10 October 2007 (UTC)

title: User talk:221.128.190.63