tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@tomitribe.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Fri, 17 Oct 2014 06:22:56 GMT
purequery questions are for IBMs ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-10-17 8:19 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> @Romain
>
> Is there something similar to checkDs that I can do when using EJBs,
> Container Managed tx and PureQuery (which in turn gets connections from an
> injected datasource and fires queries...). That is checkDs without JPA?
>
> Regards
> LF
>
> On Thu, Oct 16, 2014 at 3:48 PM, Lars-Fredrik Smedberg <itsmeden@gmail.com>
> wrote:
>
>> True haha... will have a look at it... I really want to learn the details
>> (and in my case have to due to some design we are in the middle of)...
>>
>> Anyway... thanks for all help, preciate it!
>>
>> /LF
>>
>> On Thu, Oct 16, 2014 at 3:42 PM, Romain Manni-Bucau <
>> rmannibucau@tomitribe.com> wrote:
>>
>>> hehe you are curious, read
>>> org.apache.openjpa.kernel.BrokerImpl#beforeCompletion. It basically
>>> check all state of the entities
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2014-10-16 15:38 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>>> > Thanks for the answer
>>> >
>>> > What exactly is involved in a checkDs1() call?
>>> >
>>> > Regards
>>> > LF
>>> >
>>> > On Thu, Oct 16, 2014 at 3:33 PM, Romain Manni-Bucau <
>>> > rmannibucau@tomitribe.com> wrote:
>>> >
>>> >> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>>> >> > Thanks again, see below.
>>> >> >
>>> >> > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau <
>>> >> > rmannibucau@tomitribe.com> wrote:
>>> >> >
>>> >> >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg <
>>> itsmeden@gmail.com>:
>>> >> >> > Just one more thing I forgot to put in the other mail
>>> >> >> >
>>> >> >> > With "Depend, using ManagedConnection it will be green
but it
>>> will not
>>> >> >> do what
>>> >> >> > you expect." you mean that I will think it runs in a tx
but its
>>> not
>>> >> and
>>> >> >> in
>>> >> >> > case of failure I might get inconsistency?
>>> >> >> >
>>> >> >>
>>> >> >> right, if datasource2.commit() fails but ds1.commit() passed
then
>>> you
>>> >> >> are not consistent. Of course with jpa it is not that impacting
>>> since
>>> >> >>
>>> >> >
>>> >> > Could you please explain how jpa tries to solve this? I guess it
>>> will not
>>> >> > completely remove the consisitency risk but only lower the risk?
>>> >> >
>>> >>
>>> >> It doesn't but it limits it in practise. It basically do a check
>>> >> before calling commit. All checks pass before commit:
>>> >>
>>> >> checkDs1();
>>> >> checkDs2();
>>> >> commitDs1();
>>> >> commitDs2();
>>> >>
>>> >> so it avoids half of the ds2 commit fails but not ds1.
>>> >>
>>> >> >
>>> >> >> the provider checks it before committing.
>>> >> >>
>>> >> >>
>>> >> > So I guess in our case: non xa datasources with multiple connections
>>> >> within
>>> >> > a transaction we are not guaranteed consistency?
>>> >> >
>>> >>
>>> >> Yep
>>> >>
>>> >> > I see also that some db vendors (MQ SQL) has some optimization
so
>>> >> > transactions involving multiple connections from different
>>> datasources
>>> >> but
>>> >> > from the same db is not promoted to a distributed tx
>>> >> >
>>> >> > => Is that only vendor specific or is that according to spec
to not
>>> >> promote
>>> >> > it in certain situations?
>>> >> >
>>> >>
>>> >> vendor
>>> >>
>>> >> >
>>> >> > resource = datasource != underlying db (without using openejb
>>> >> >> aliases). Each datasource has its own pool of connection and
then
>>> its
>>> >> >> own JTA integration (different Xid).
>>> >> >>
>>> >> >> > Regards
>>> >> >> > LF
>>> >> >> >
>>> >> >> > On Thu, Oct 16, 2014 at 12:59 PM, Romain Manni-Bucau <
>>> >> >> > rmannibucau@tomitribe.com> wrote:
>>> >> >> >
>>> >> >> >> Well I don't know websphere enough to answer to the
related
>>> question
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> 2014-10-16 12:55 GMT+02:00 Lars-Fredrik Smedberg <
>>> itsmeden@gmail.com
>>> >> >:
>>> >> >> >> > Thanks Romain, please see if you can help me
on the follow up
>>> >> below?
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Thu, Oct 16, 2014 at 9:33 AM, Romain Manni-Bucau
<
>>> >> >> >> rmannibucau@gmail.com>
>>> >> >> >> > wrote:
>>> >> >> >> >
>>> >> >> >> >> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik Smedberg
<
>>> >> itsmeden@gmail.com
>>> >> >> >:
>>> >> >> >> >> > @Romain
>>> >> >> >> >> >
>>> >> >> >> >> > I can see in the ManagedConnection code
that the reused
>>> >> Connection
>>> >> >> is
>>> >> >> >> per
>>> >> >> >> >> > Transaction per DataSource.
>>> >> >> >> >> >
>>> >> >> >> >> > So if I use 2 x DataSource (pointing
to the same DB but with
>>> >> >> different
>>> >> >> >> >> > properties set) I will within a transaction
use 2
>>> connections,
>>> >> >> >> correct?
>>> >> >> >> >> >
>>> >> >> >> >> yep
>>> >> >> >> >>
>>> >> >> >> >> > Will this result in a distributed transaction?
>>> >> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> No, this ManagedConnection is to get JTA
integration "locally"
>>> >> (ie we
>>> >> >> >> >> integrate locally with XA hooks but it is
not distributed).
>>> For
>>> >> that
>>> >> >> >> >> you have to use a really XA datasource.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> > We use WebSphere in test/production and the driver
included in
>>> >> >> >> db2jcc4.jar.
>>> >> >> >> >
>>> >> >> >> > As far as I understand from the documentation
if the type
>>> >> attribute of
>>> >> >> >> the
>>> >> >> >> > datasource element in the configuration is not
set it will
>>> search
>>> >> the
>>> >> >> >> > driver jar for datasources in the following order:
>>> >> >> >> >
>>> >> >> >> > javax.sql.ConnectionPoolDataSource
>>> >> >> >> > javax.sql.DataSource
>>> >> >> >> > javax.sql.XADataSource
>>> >> >> >> >
>>> >> >> >> > In our testconfiguration we do not specify the
type attribute
>>> so I
>>> >> >> assume
>>> >> >> >> > we are NOT using XA datasource. correct?
>>> >> >> >> >
>>> >> >> >> > So some questions on the above:
>>> >> >> >> >
>>> >> >> >> > 1. In what cases will I not need a distributed
tx?
>>> >> >> >>
>>> >> >> >> You don't need it either when you have a single or
totally
>>> >> decorelated
>>> >> >> >> resources (datasource for instane) or when you want
performances
>>> (XA
>>> >> >> >> is slow) and can accept some manual operations to
fix
>>> inconsistency
>>> >> if
>>> >> >> >> it happens (should be rare)
>>> >> >> >>
>>> >> >> >> > a) A tx with 1 connection to a DB? No!
>>> >> >> >> > b) A tx with 2 connections (from seperate datasources)
>>> connected to
>>> >> >> the
>>> >> >> >> > same DB? <== ??
>>> >> >> >> > c) A tx with 2 connections (from seperate datasources)
>>> connected to
>>> >> >> >> > different DBs? Yes!
>>> >> >> >> > d) A tx with 1 connection to a DB and e.g. JMS?
Yes!
>>> >> >> >> >
>>> >> >> >> > 2. If I have a scenario that requires a distributed
and the
>>> >> datasource
>>> >> >> >> that
>>> >> >> >> > is used is NOT an XA datasource what will happen?
Exception?
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> Depend, using ManagedConnection it will be green but
it will not
>>> do
>>> >> >> >> what you expect.
>>> >> >> >>
>>> >> >> >> > Thanks
>>> >> >> >> >
>>> >> >> >> > Regards
>>> >> >> >> > Lars-Fredrik
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> > Regards
>>> >> >> >> >> > LF
>>> >> >> >> >> >
>>> >> >> >> >> > On Wed, Oct 15, 2014 at 8:48 AM, Romain
Manni-Bucau <
>>> >> >> >> >> rmannibucau@gmail.com>
>>> >> >> >> >> > wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >> Hi
>>> >> >> >> >> >>
>>> >> >> >> >> >> that's the global idea yes
>>> >> >> >> >> >>
>>> >> >> >> >> >> about transaction manager:
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.geronimo.components/geronimo-transaction/3.1.1/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#TransactionManagerImpl
>>> >> >> >> >> >> is th eone
>>> >> >> >> >> >>
>>> >> >> >> >> >> idea is simple: invoke registered
hooks when needed and
>>> just
>>> >> >> manage
>>> >> >> >> >> >> the lifecycle then EJB containers
start/stop these hooks
>>> >> calling
>>> >> >> the
>>> >> >> >> >> >> tx mgr (look SingletonContainer
hierarchy in openejb-core
>>> for
>>> >> >> >> >> >> instance)
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> Romain Manni-Bucau
>>> >> >> >> >> >> @rmannibucau
>>> >> >> >> >> >> http://www.tomitribe.com
>>> >> >> >> >> >> http://rmannibucau.wordpress.com
>>> >> >> >> >> >> https://github.com/rmannibucau
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> 2014-10-15 1:19 GMT+02:00 Lars-Fredrik
Smedberg <
>>> >> >> itsmeden@gmail.com
>>> >> >> >> >:
>>> >> >> >> >> >> > Hi Romain
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Thanks for the link to the
ManagedConnection, some
>>> questions
>>> >> on
>>> >> >> it
>>> >> >> >> >> (so I
>>> >> >> >> >> >> > understand it correctly)
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > - The connection is bound to
the tx when the first
>>> method is
>>> >> >> >> called on
>>> >> >> >> >> >> the
>>> >> >> >> >> >> > connect (except for toString,
equals and hashcode), and
>>> if
>>> >> its
>>> >> >> not
>>> >> >> >> >> >> already
>>> >> >> >> >> >> > bound, correct?
>>> >> >> >> >> >> > - Do I understand correctly
that I will always use (using
>>> >> >> >> delegation
>>> >> >> >> >> in
>>> >> >> >> >> >> the
>>> >> >> >> >> >> > proxy) the same connection
(the one bound to the tx)
>>> >> regardless
>>> >> >> of
>>> >> >> >> if
>>> >> >> >> >> I
>>> >> >> >> >> >> use
>>> >> >> >> >> >> > getConnection()/close() multiple
times within an EJB that
>>> >> >> handles
>>> >> >> >> tx?
>>> >> >> >> >> >> > - In the above case the connection
I think I'm using
>>> (when I
>>> >> >> simple
>>> >> >> >> >> look
>>> >> >> >> >> >> at
>>> >> >> >> >> >> > the code) is returned to the
pool and the bound one is
>>> used?
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Where can I get more understanding
of the
>>> TransactionManager
>>> >> and
>>> >> >> >> its
>>> >> >> >> >> >> > relation to the transactions
annotated in the EJB?
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Very nice to take a look at
the code, really makes the
>>> >> >> >> understanding
>>> >> >> >> >> alot
>>> >> >> >> >> >> > easier, thanks!
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > /LF
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Wed, Oct 15, 2014 at 1:03
AM, Romain Manni-Bucau <
>>> >> >> >> >> >> rmannibucau@gmail.com>
>>> >> >> >> >> >> > wrote:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >> Hi
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> this is actually more bound
to JTA (you can read
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/managed/local/ManagedConnection.java
>>> >> >> >> >> >> >> )
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> 2014-10-15 0:14 GMT+02:00
Lars-Fredrik Smedberg <
>>> >> >> >> itsmeden@gmail.com
>>> >> >> >> >> >:
>>> >> >> >> >> >> >> > Hi
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Using JDBC, creating
a connection and setting it to
>>> auto
>>> >> >> commit
>>> >> >> >> >> false
>>> >> >> >> >> >> to
>>> >> >> >> >> >> >> be
>>> >> >> >> >> >> >> > able to group more
than one statement into a single
>>> >> >> transaction
>>> >> >> >> I
>>> >> >> >> >> >> >> > understand.
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > - Is it possible to
compare that to an EJB with a
>>> >> >> >> >> >> @TransactionAttribute
>>> >> >> >> >> >> >> > set? I would like
to understand more in detail how
>>> the EJB
>>> >> >> >> handles
>>> >> >> >> >> >> >> > transactions, datasources
and connections "under the
>>> >> hood".
>>> >> >> >> >> >> >> > (it all comes from
a discussion with a DBA)
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > If I use @Resource
to inject a Datasource and use to
>>> >> >> retrieve a
>>> >> >> >> >> >> >> connection
>>> >> >> >> >> >> >> > I usually call close
on it after I done using it,
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > - Will close on the
connection actually close it or is
>>> >> that
>>> >> >> >> done at
>>> >> >> >> >> >> the
>>> >> >> >> >> >> >> > commit of the transaction
(assume we are in an EJB
>>> with
>>> >> >> >> >> >> >> > @TransactionAttribute
set)?
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> will be done later to support
rollback
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> > - Will the container
automatically set auto commit
>>> false
>>> >> to
>>> >> >> any
>>> >> >> >> >> >> >> connections
>>> >> >> >> >> >> >> > retrieved within the
transaction?
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> all JTA ones, can also
depend on JPA provider config
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> > - ... and many more
questions :)
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Maybe I'm mixing the
topics a bit but it would be
>>> really
>>> >> >> great
>>> >> >> >> to
>>> >> >> >> >> >> >> > understand it all
more in-depth to be able to have the
>>> >> >> >> >> understanding
>>> >> >> >> >> >> and
>>> >> >> >> >> >> >> > discuss it with the
DBA.
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Thanks
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > --
>>> >> >> >> >> >> >> > Med vänlig hälsning
/ Best regards
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Lars-Fredrik Smedberg
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> >> >> >> >> >> > The information contained
in this electronic message
>>> and
>>> >> any
>>> >> >> >> >> >> >> > attachments to this
message are intended for the
>>> exclusive
>>> >> >> use
>>> >> >> >> of
>>> >> >> >> >> the
>>> >> >> >> >> >> >> > address(es) and may
contain confidential or privileged
>>> >> >> >> >> information. If
>>> >> >> >> >> >> >> > you are not the intended
recipient, please notify
>>> >> >> Lars-Fredrik
>>> >> >> >> >> >> Smedberg
>>> >> >> >> >> >> >> > immediately at itsmeden@gmail.com,
and destroy all
>>> >> copies of
>>> >> >> >> this
>>> >> >> >> >> >> >> > message and any attachments.
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > --
>>> >> >> >> >> >> > Med vänlig hälsning / Best
regards
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Lars-Fredrik Smedberg
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> >> >> >> >> > The information contained in
this electronic message and
>>> any
>>> >> >> >> >> >> > attachments to this message
are intended for the
>>> exclusive
>>> >> use
>>> >> >> of
>>> >> >> >> the
>>> >> >> >> >> >> > address(es) and may contain
confidential or privileged
>>> >> >> >> information. If
>>> >> >> >> >> >> > you are not the intended recipient,
please notify
>>> >> Lars-Fredrik
>>> >> >> >> >> Smedberg
>>> >> >> >> >> >> > immediately at itsmeden@gmail.com,
and destroy all
>>> copies of
>>> >> >> this
>>> >> >> >> >> >> > message and any attachments.
>>> >> >> >> >> >>
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > --
>>> >> >> >> >> > Med vänlig hälsning / Best regards
>>> >> >> >> >> >
>>> >> >> >> >> > Lars-Fredrik Smedberg
>>> >> >> >> >> >
>>> >> >> >> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> >> >> >> > The information contained in this electronic
message and any
>>> >> >> >> >> > attachments to this message are intended
for the exclusive
>>> use
>>> >> of
>>> >> >> the
>>> >> >> >> >> > address(es) and may contain confidential
or privileged
>>> >> >> information. If
>>> >> >> >> >> > you are not the intended recipient,
please notify
>>> Lars-Fredrik
>>> >> >> >> Smedberg
>>> >> >> >> >> > immediately at itsmeden@gmail.com, and
destroy all copies
>>> of
>>> >> this
>>> >> >> >> >> > message and any attachments.
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > --
>>> >> >> >> > Med vänlig hälsning / Best regards
>>> >> >> >> >
>>> >> >> >> > Lars-Fredrik Smedberg
>>> >> >> >> >
>>> >> >> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> >> >> > The information contained in this electronic
message and any
>>> >> >> >> > attachments to this message are intended for
the exclusive use
>>> of
>>> >> the
>>> >> >> >> > address(es) and may contain confidential or privileged
>>> >> information. If
>>> >> >> >> > you are not the intended recipient, please notify
Lars-Fredrik
>>> >> >> Smedberg
>>> >> >> >> > immediately at itsmeden@gmail.com, and destroy
all copies of
>>> this
>>> >> >> >> > message and any attachments.
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Med vänlig hälsning / Best regards
>>> >> >> >
>>> >> >> > Lars-Fredrik Smedberg
>>> >> >> >
>>> >> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> >> > The information contained in this electronic message and
any
>>> >> >> > attachments to this message are intended for the exclusive
use of
>>> the
>>> >> >> > address(es) and may contain confidential or privileged
>>> information. If
>>> >> >> > you are not the intended recipient, please notify Lars-Fredrik
>>> >> Smedberg
>>> >> >> > immediately at itsmeden@gmail.com, and destroy all copies
of this
>>> >> >> > message and any attachments.
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Med vänlig hälsning / Best regards
>>> >> >
>>> >> > Lars-Fredrik Smedberg
>>> >> >
>>> >> > STATEMENT OF CONFIDENTIALITY:
>>> >> > The information contained in this electronic message and any
>>> >> > attachments to this message are intended for the exclusive use
of the
>>> >> > address(es) and may contain confidential or privileged information.
>>> If
>>> >> > you are not the intended recipient, please notify Lars-Fredrik
>>> Smedberg
>>> >> > immediately at itsmeden@gmail.com, and destroy all copies of this
>>> >> > message and any attachments.
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Med vänlig hälsning / Best regards
>>> >
>>> > Lars-Fredrik Smedberg
>>> >
>>> > STATEMENT OF CONFIDENTIALITY:
>>> > The information contained in this electronic message and any
>>> > attachments to this message are intended for the exclusive use of the
>>> > address(es) and may contain confidential or privileged information. If
>>> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
>>> > immediately at itsmeden@gmail.com, and destroy all copies of this
>>> > message and any attachments.
>>>
>>
>>
>>
>> --
>> Med vänlig hälsning / Best regards
>>
>> Lars-Fredrik Smedberg
>>
>> STATEMENT OF CONFIDENTIALITY:
>> The information contained in this electronic message and any
>> attachments to this message are intended for the exclusive use of the
>> address(es) and may contain confidential or privileged information. If
>> you are not the intended recipient, please notify Lars-Fredrik Smedberg
>> immediately at itsmeden@gmail.com, and destroy all copies of this
>> message and any attachments.
>>
>
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.

Mime
View raw message