With msg.sender the owner can be a contract.
With tx.origin the owner can never be a contract.
In a simple call chain A->B->C->D, inside D msg.sender will be C, and tx.origin will be A.
msg.sender is preferred for the flexibility it provides. Furthermore, for Serenity, even though it's a while out, Vitalik recommends avoiding tx.origin: How do I make my DAPP "Serenity-Proof?"
Carefully consider if you really ever need to use tx.origin. Remember, you may not be the only user of your contract. Other people may want to use your contract and want to interact with it via a contract they've been written.
If the origin is really desired in D, then each of the functions in the contracts B, C, D could take an extra parameter to propagate the origin: A would pass its address (this) to B, B would pass the value to C, and C would pass it to D.
EDIT: To emphasize the comment by @WBT below, a contract that uses a passed in value for the origin, must be very careful in how it uses the origin: anyone can pass in a value that is not the real origin.
Best Answer
You're using web3.js:
If
testfuncin Solidity is labelled withconstant, it will behave as a call #3. Otherwise, it will behave as a transaction #2.is an explicit transaction that will be broadcasted to the network and potentially mined into a block. The return value will always be a transaction hash. This costs ether (computed by gas used X gas price).
is an explicit local invocation of
testfuncthat does not broadcast or publish anything on the blockchain. The return value is determined by the Solidity code oftestfunc. This does not cost ether (though gas is still used).For a detailed explanation see What is the difference between a transaction and a call?