bash does not provide a return statement to return custom values from a function. The return statement is only used to return a numeric status code to the calling function which can be retrieved with $?.
Long story made short, use a recent bash version (>= 4.3) and use the declare -n statement to declare a reference to the variable where the result will be stored, and pass the name of this variable as a parameter to the function:
#!/bin/bash
someFunction() {
declare -n __resultVar=$1
local someValue="Hello World"
# The next statement assigns the value of the local variable to the variable
# passed as parameter
__resultVar=${someValue}
}
# call the function and pass the name of the result variable
someFunction theResult
echo ${theResult}
Sometimes it is still easiest (especially when there is only a command line terminal available) to directly edit files like /etc/passwd, /etc/hosts etc. with a plain text editor. When I today just wanted to change the login shell of a user on an Oracle Enterprise Linux installation, I simply changed /bin/csh to /bin/bash for the corresponding entry in /etc/passwd.
However, the surprise was that the new entry was not considered when re-logging in. This is where nscd comes into play. From the man page:
NSCD(8) Linux Programmer's Manual NSCD(8)
NAME
/usr/sbin/nscd - name service cache daemon
DESCRIPTION
Nscd is a daemon that provides a cache for the most common name service requests. ...
Among those most common name service requests are lookups into the /etc/hosts, /etc/group and /etc/hosts files.
Actually the nscd daemon also watches the respective files for changes, but it might take several minutes until it picks up the modified files.To clear the nscd cache immediately, simply call nscd with the -i switch and the name of the lookup database which needs to be reloaded:
$ /usr/sbin/nscd -i passwd
By the way, stopping and re-starting the nscd daemon through /etc/init.d/nscd is not enough – the daemon still remembers its cached entries afterwards.
ADFbc can be configured with different locking modes, in particular pessimistic and optimistic locking. Since pessimistic locking might create pending row-level locks on the database, the general recommendation is to use optimistic locking for web applications, to achieve a good performance. For more information, see Fusion Application Developers Guide, 40.11 Keeping Pending Changes in the Middle Tier.
To configure optimistic locking, either set the jbo.locking.mode property of your application module configuration to “optimistic” or configure the locking mode globally in .adf/META-INF/adf-config.xml:
If configured, the setting from adf-config.xml takes precedence over the application module property.
Detecting lost updates
With optimistic locking, when more than one user is working on the same set of data, it can happen that the same attribute is modified by more than one user at the same time. When the first user commits his transaction, the updated value is written back to the database – other users would never see these (probably important) modifications, and when the next user also commits the transaction, his modifications would be written back to the database, overwriting the modifications from the first user. This phenomenon is also known as “lost update“. ADF has the ability to detect attempts to update data which has been modified in parallel. When the data is committed (e.g. by executing the “commit” action on the application module), ADF performs the following actions:
1. The row is locked on the database by executing an SELECT ... FOR UPDATE NOWAIT query, like
SELECT DATA, ID
FROM SIMPLE SimpleEO
WHERE ID=:1
FOR UPDATE NOWAIT
2. ADF then compares the values selected through this query against the current values stored in the entity object. If any of the attribute values have changed, ADF will display an error dialog:
Improving performance by using a change indicator
Comparing all attributes in the EO in step 2 above can be time consuming, especially if the EO contains many attributes. To improve the performance, it is possible to define one of the attributes as a change indicator:
NOTE: In several books, it says “one or more attributes can be selected as change indicator” – however, at least with JDeveloper 11.1.1.7, only one attribute of an EO can be selected as change indicator. If setting the flag on one attribute, JDeveloper automatically resets the flag on the other attribute where it has previously been set. This is also consistent with the Javadoc, where it says “This method uses the ChangeIndicator attribute, if it is present, for the comparison. If ChangeIndicator is not present, then this method compares the data for overlapping columns between the entity and the given array.”
When a change indicator is defined on the EO, the framework only performs the comparison for the attribute marked as such, instead of for every entity attribute. Note however that the SQL statement still queries all attributes!
An important detail is that the change indicator attribute needs to be a system field which is automatically updated in the background whenever the row in the database is modified, for example through an ON UPDATE database trigger. Do not use an attribute which can be edited by the user – otherwise, ADF assumes that the record has been modified by another user even though that is not the case. This check is not done when committing the data, but already when changing the attribute value (means, when calling the setAttribute() method on the EO). This might result in the following error message on the ADF rich client UI (note the different representation as a popup window, not as a dialog like above):
public interface Constants {
static int DML_DELETE = 0x02;
static int DML_INSERT = 0x05;
static int DML_UPDATE = 0x10;
}
Since Java 5, a much better alternative is to use an enum. If possible, code like the above which only defines constants should be converted into a corresponding enum. However, sometimes this is not possible, for example when using a library where the source code is not available. Then, we can still take advantage of enums in our own code by wrapping the legacy constants into an enum type. By default, a Java enum only allows to map from the the enum name to the enum itself, but in our scenario we also need to be able to map the legacy integer constants to the corresponding enum.
The following code shows how the above interface could be wrapped into an enum:
public enum ConstEnum {
DML_DELETE(Constants.DML_DELETE),
DML_INSERT(Constants.DML_INSERT),
DML_UPDATE(Constants.DML_UPDATE);
private int constValue;
// we need to create a reverse map for the enum in order to allow reverse lookups
private static HashMap<Integer, ConstEnum> revMap = new HashMap<>();
static {
for (ConstEnum e : values()) {
revMap.put(e.value(), e);
}
}
// private constructor for the integer value
private ConstEnum(int someValue) {
constValue = someValue;
}
public int value() {
return constValue;
}
public static ConstEnum enumFor(int value) {
ConstEnum result = revMap.get(value);
if (result == null) {
throw new NoSuchElementException(ConstEnum.class.getName() + " for " + value);
}
return result;
}
}
The core of this code is the revMap hashmap which is initialized in the static initializer and puts all available enum objects and their corresponding integer values into a hashmap, so that we can look up the enum object by its integer value, which is done in the enumFor() method. The static values() method is provided automatically by the java compiler for all enum types. The following samples show how the enum type can now be used:
List all available values:
for (ConstEnum val : ConstEnum.values()) {
System.err.println(val + "=" + val.value());
}
DML_DELETE=2
DML_INSERT=5
DML_UPDATE=16
Convert legacy int value into enum:
int someValue = 5;
ConstEnum e = ConstEnum.enumFor(someValue);
System.err.println(e + "=" + e.value());
DML_INSERT=5
Switch on a legacy int value:
someValue = 2;
ConstEnum e = ConstEnum.enumFor(someValue);
switch(e) {
case DML_DELETE : System.err.println("DELETE"); break;
case DML_INSERT : System.err.println("INSERT"); break;
case DML_UPDATE : System.err.println("UPDATE"); break;
}
